Мониторинг на софтуерни лицензи. Отделна инсталация на библиотека за по-ранни версии
- урок
Много компании използват 1C като основна платформа за автоматизация. Така се случи и с нас. Процесът на създаване на платформата обаче беше извършен без подходящ подход, във връзка с което първоначално имахме 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: Резултат: 1
Използване на пароли 15213 - 28875
LOCALHASP_HASPSTATUS: Номерът на версията на API е 8.0
порт номер 201
Тип ключ: HASP4 M4
LOCALHASP_HASPGENERATION: Добре, HASP4 е свързан.
LOCALHASP_HASPNETSTATUS: свързаният ключ е HASP4 Net 20
MEMOHASP_HASPID: 436444258 (десетичен), 0x1a039c62 (шестнадесетичен)LOCALHASP_ENCODEDATA: Добре.
53 C1 F1AF | 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: Резултат: 1 . Да ти кажа всичко е в реда на нещата. По-нататък се пише кой ключ е поставен.
Ако обаче има някакъв проблем, съобщението се показва по-кратко:
Това е проста демонстрационна програма за ключа HASP4
Авторско право Aladdin Knowledge Systems Ltd.LOCALHASP_ISHASP: Неуспешно: състояние = -100
Освен това всъщност няма значение какво се случва с ключа, може да не е поставен, услугата да не работи или нещо друго. Виждал съм само две LOCALHASP_ISHASP стойности досега. Това е или: Резултат: 1 или: Неуспешно: статус = -100. И второто винаги отговаряше на неработоспособност, а първото винаги означаваше, че всичко е наред. Не намерих документация за този пакет, така че не можах да разбера какви други състояния има.
Готово с ключа. Не трябва да забравяме, че вашият новоизсечен ключ ще се появи в монитора на ключовете само когато от него бъде взет поне един лиценз. След това Aladdin Monitor ще покаже информацията, която обикновено показва: това е типа ключ, броя на взетите лицензи, общия брой лицензи, кой точно е взел лиценза и времето за изчакване.
Доста лесно е да принудите това, достатъчно е ръчно да посочите нов мениджър на лицензи в клиента nethasp.ini. Но за настройката на клиента малко по-късно.
От този момент нататък първоначалната задача може да се счита за изпълнена. Сега можем да създадем няколко виртуални машини паралелно, в количество, съответстващо на броя на наличните физически ключове. Ресурси като virtualka консумират, разбира се, пени.
Проблеми и решения
Единична точка на повреда
Първият проблем, който се създава и е видим, е създаването на точка на отказ. Ако преди това ключовете са били разпределени на различни сървъри и повредата на повече от един ключ е практически изключена, тогава в този случай повредата на физическия сървър може да доведе до повреда на цялата система 1C, т.к. клиентите ще отпаднат в рамките на според мен 600 секунди и след кратко време всички ще отпаднат и няма да могат да се върнат в системата. Какво ще последва след подобен инцидент не може да се каже. Има две решения и те са насочени в различни посоки. Първото решение е да се използва конфигурация на ESX при отказ. Това обаче има смисъл, ако вашата компания вече е внедрила тази система и вече е изпълнила редица изисквания за поддържане на работоспособност в случай на повреда на който и да е компонент. Друго решение е по-тривиално:Ние създаваме група от A записи в DNS на нашата компания. Например key1, key2, key3 и така нататък. Въвеждаме DNS имена в клиенти nethasp.ini, разпространяваме файла с помощта на групова политика. Така получаваме доста гъвкава структура за достъп. В този случай, след откриване на значителен проблем с виртуалния сървър esx, можете бързо да преместите ключовете към всякакви други сървъри, вкл. към работните станции на всички служители. Успоредно с това заместваме A записи с нови. За известно време кеша на клиентите ще свърши и те отново ще могат да получат нов лиценз и да продължат да работят.
Препоръчвам да зададете обратни DNS записи за ключове, в противен случай мониторът на Аладин няма да покаже името на хоста, а ще покаже само ID на мениджъра на лицензи, което не е много удобно.
Ако вашата компания и всичко използва метод за доставка на излъчван ключ, тогава всичко е опростено и преместването на ключа към друг хост в рамките на излъчвания домейн няма да повлияе на работата ви по никакъв начин.
Ключовете падат
Има един доста често срещан проблем. Ключовете падат. Не се наблюдава обаче особена връзка. Това се случва на различни контролери, дори на различни хост системи. Когато преместих ключовете и временно ги поставих на друго място под контрола на VMware Player, ключовете често падаха. Това се изразява доста тривиално. При заявка на haspdemo се появява редът LOCALHASP_ISHASP: Failed: status = -100. Въпреки че ключът е поставен и открит. dmseg показва редове, които не са напълно разбрани: usb 2-2.1: usbfs: USBDEVFS_CONTROL неуспешно cmd aksusbd rqt 192 rq 139 len 8 ret -110Проблемът се решава толкова тривиално, колкото изглежда - чрез рестартиране на услугата. Но утайката остава и докато това не стане, сървърът няма да раздаде ключовете. Тъй като искам системата да работи безупречно, беше решено да напиша скрипт, който да възстанови самия мениджър на лицензи. И така, с помощта на приятел беше написан скрипт, който изпълнява haspdemo и се опитва да разбере дали състоянието се връща нормално или не:
[ "`haspdemo | sed -n "s/^LOCALHASP_ISHASP.* \(\-\?*\)$/\1/p"`" == "-100" ] && рестартиране на услугата haspd
Освен това, този скрипт се вмъква в стартирането на CRON всяка минута и това е всичко. Дори ако вашата система няма проблем с падането на портовете, този скрипт, мисля, няма да навреди.
Проблем с откриването на клиентски ключ
И има такъв проблем. Състои се в това, че клиентът след загуба на ключа може да не иска да вземе нов ключ. Също така този проблем може да се изрази в други прояви. Например, ако сте променили пътищата към ключовете във файла nethasp.ini, тогава клиентското приложение може доста весело да продължи да съобщава, че няма ключове и никога не ги е виждало. Ако не сте готови за такава реакция, тогава проблемът става много неприятен и започвате трескаво да проверявате работата на цялата система и да проклинате прякорите на 1C, защото всичко работи, но GlavBukh или, ако има късмет, генералът, сега не можете да влезете в 1Sku по някаква неизвестна причина и се чувствате като идиот, вместо да решите проблема бързо. Въпреки това, едно доста просто решение е помогнало досега. Необходимо е да изчистите кеша на 1C от потребителския профил. По едно време намерих отделен файл, който отговаря за тази информация, забравих кой :(Ключовете може просто да спрат да работят
Никой не е имунизиран от повреда на оборудването. И тези жалки ключове също могат да спрат да работят. И най-важното в този случай е да разберете за това възможно най-рано. За да направим това, ще използваме системата за наблюдение Zabbix. Разбира се, разполагането му само за наблюдение на ключовете е безсмислено, но ако Zabbix вече е инсталиран, тогава защо да не прикачите наблюдение на състоянието на ключовете към него.За да направим това, трябва да напишем собствен скрипт във файла с настройки на агента. Търсим конфигурационния файл на инсталирания zabbix_agent, той се нарича zabbix_agentd.conf. Отворете го и добавете линията
Потребителски параметър=hasp.status,haspdemo | grep "^LOCALHASP_ISHASP" | sed "s/^.* \(\-\?*\)$/\1/g"
Това ще позволи по команда да събере числова стойност в полето LOCALHASP_ISHASP. В самия zabbix всичко се добавя вече примитивно, ние създаваме вещза желания хост или шаблон, като Типпосочвам zabbix агент,посочете като ключов параметър hasp.статус. Тип стойност - плавам. При желание създаваме тригер, чрез който ще получите писмо или SMS, че ключът не работи. По-добре е да конфигурирате този тригер по такъв начин, че да изисква поне 2 удара и да покрива времето, необходимо за скрипта за автоматично възстановяване, описан по-горе, в противен случай ще се появят фалшиви съобщения за проблеми с ключа.
При правилни настройки, само ако ключът е напълно неработещ, ще получите известие за проблеми.
Бонус
Оказа се изненада за мен, но много хора наистина не знаят, че е възможно да принудите клиентските части на 1C да търсят ключове на определени IP адреси, използвайки TCP или UDP връзка. Наистина, много хора настройват инфраструктурата си така, че всеки излъчван домейн да има достатъчен брой ключове. Това е дивотия. За тези, които все още не знаят, ето кратко ръководство:За да контролирате достъпа до hasp ключа, на клиента има файл nethasp.ini. Той се намира в папката \conf на директорията 1C. Интересуваме се от секцията В този раздел трябва да премахнем коментарите или да създадем следните опции:
- NH_SERVER_ADDR. Тук посочваме списък с DNS имена или IP адреси на сървъри с мениджър на лицензи, разделени със запетаи.
- NH_USE_BROADCAST. Задайте стойността на Disabled.
- NH_TCPIP_METHOD. Методът по подразбиране е UDP. Можете да промените на TCP, но като цяло няма сериозна нужда от това.
Друга точка относно показването на клавиши в монитора на Aladdin. Противно на общоприетото схващане, безплатните лицензи са не само тези лицензи, които не се използват в монитора на Aladdin, но и тези, които имат 0 в полето Timeout.Стойностите обикновено изчезват в рамките на 36 часа, но лицензите все още се считат за безплатни.
В заключение
Дълго мислих дали има смисъл от такава статия, в края на краищата всичко това може да се намери в интернет, но като се има предвид времето, което аз самият отделих, за да събера цялата информация, реших, че ще бъде много добре, ако поне някой това Статията ще бъде полезна и ще спести време.
Въпрос: Мониторинг на софтуерни лицензи
Добър ден.
Windows сървър 2008 + SQL сървър + сървър 1C 8.2.
Софтуерните лицензи са инсталирани на сървъра 10 бр + 5 бр = 15 бр.
Максимален брой едновременно работещи потребители - 13 бр.
Базата е една. Съответно потребителите изпълняват само един екземпляр на програмата.
Понякога някои потребители не могат да въведат 1s (ключът за защита на програмата не е намерен). Случайно се оказа, че потребителите могат да влязат отново, ако конкретен потребител рестартира 1s-ku. Съответно, както разбирам, този потребител изразходва повече от един лиценз в хода на работата си.
Въпрос: как да проследим кои лицензи къде са отишли и как да се справим с такива замразени лицензи?
Отговор:
Хубава обработка, много необходима! Но не работи)
(ExternalProcessing.MonitoringLicenses.ObjectModule(53)): (ExternalProcessing.MonitoringLicenses.ObjectModule(23)): Грешка при извикване на конструктор (COMObject): -2147221005(0x800401F3): Невалиден низ от клас
ThrowException DescriptionError();Може би някой би могъл да го поправи?
Въпрос: Проблем със софтуерните лицензи на 1c сървър
Здравейте скъпи форумци! Моля, кажете ми, ако някой се е сблъсквал с това как да бъда в такава ситуация.
Първоначално: имаше база 1s KA 1.1, 1s 8.2, платформа 8.2.19.130, файл на терминалния сървър. На самия сървър беше инсталиран ключ за 10 потребителски лиценза и 5 софтуерни лиценза (лицензният файл беше в C:\ProgramData\1C\1Cv82\conf). Потребителите са работили през терминални сесии.
Стана: прехвърлен към версията клиент-сървър (1s x64 сървър, платформа 8.3.8.2054), Postgres subd, потребителите работят директно от работните си места. Компютрите получават лиценз по мрежата от сървър.
Проблемът е, че 1s сървърът не вижда софтуерни лицензи. Лицензният файл беше копиран в папката conf на сървъра (C:\Program Files\1cv8\conf), в папката с лицензи (C:\Program Files\1cv8\8.3.8.2054\licenses - въпреки че разбирам, че лицензът не трябва да се съхранявани тук), а също и към папката на платформата по същите пътища (C:\Program Files (x86)\1cv8\conf, C:\Program Files (x86)\1cv8\8.3.8.2054\licenses).
Доколкото чета в интернет, софтуерните ключове се търсят и взимат на първо място, така че трябва да работи ...
Но тъжни мисли ме посещават, че при инсталиране на софтуерен лиценз за 5 потребители, нещо "зашито" в регистъра, което го свързва с оригиналната схема, на 1s 8.2 и че сървърът 8.3 не вижда. Тъй като ще трябва да активирате нов пин код на софтуерния лиценз, моля помогнете, кажете ми дали това наистина е така??
Отговор:
При активиране на софтуерни лицензи се създава повече от един файл. Най-добре е да пишете на адреса, те ми отговориха в рамките на половин час по въпроса за деактивирането на лиценза. Те предложиха намиране и изтриване на всички 2*.lic файлове и всички conn8211.pfl файлове (или 1Сv8conn.pfl, ако версия 8.3). Съответно, поне трябва да преместите всички тези файлове, но никой няма да каже дали ще помогне, така че бих им написал писмо. Поради неправилни действия лицензният пакет може да бъде включен в черния списък.
Въпрос: Софтуерен лиценз и COM връзка
Инсталиран е софтуерен лиценз.
Когато се опитам да стартирам 1C през 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 Set 20 - какъв е този ключ? Софтуер или хардуер? Мисля, че софтуер, но защо тогава сървърът, а не клиентът?
Отговор:
Никой ли не знае от .lic файла (отговаря на номера на license.lic от регистрационната карта) да разбере какъв е лиценза?
Въпрос: Трикове за издаване на софтуерни лицензи от сървъра 1C
Здравейте всички!
Приятели, моля, кажете ми за лицензите, има някои неща, които не са ми ясни.
На сървъра е активиран софтуерен лиценз за 10 потребителя. Сървърът има 1C сървър, SQL база данни и терминален сървър.
Издаването на лицензи става по следния начин (може би това не е точно, коригирайте, ако не е правилно).
1. Ако даден потребител има платформа на своя локален компютър и той се свързва към 1c базата данни на сървъра през мрежата, тогава за всяко стартирано копие на програмата, сървърът му дава един лиценз. Тоест, ако потребител стартира 10 бази данни, тогава няма да останат лицензи на сървъра.
2. Ако потребителят се свърже чрез RDP, тогава сървърът му дава един клиентски лиценз и потребителят ще може да изпълнява неограничен брой програмни екземпляри (бази).
Основният въпрос е дали втората точка ще работи, ако потребителят се свърже с терминалния сървър чрез RDP, софтуерните лицензи ще бъдат активирани там, но няма да има 1c сървър? В терминала той ще има платформа, но без 1c сървър. Задължително ли е т.2 да работи, на сървъра на терминалите трябва да има сървър 1s?
Отговор:
такова издаване на лицензи работи с всяко локално стартиране на 1C (RDP е локално стартиране), ако лицензът не се разпространява от 1C сървъра
Въпрос: Лицензите за клиентски софтуер не се разпространяват
Добър ден.Създаден 1C клъстер (8.3.7.1759) и сървър за лицензиране. Действаше съгласно тази инструкция. (). Активиран софтуерен лиценз за много потребители на лицензния сървър. Ако стартирам клиента 1C директно на сървъра за лицензиране, тогава той обикновено получава софтуерен лиценз. От всяко друго място, ако се свържем с базата на този клъстер, се издава лиценз за хардуер. Лицензният файл се намира тук C:\ProgramData\1C\licenses
Отговор:
Има достъп за четене. Функционалност за присвояване, добавена към сървъра за лицензиране. Отметката за използване на хардуерен ключ не си струва .. И все пак получава железен лиценз ...--- Обединяване на съобщения, 28 декември 2015 г ---Окарлов каза:
Проверете друга регистрирана грешка
Ако свойствата на работния сървър на клъстера определят ограничение за броя на информационните бази на работен процес, тогава този сървър може да започне да разпространява функционалност, която е забранена от изискванията за присвояване на функционалност.
Кликнете, за да разкриете...
Клъстерът е нов - засега има само 1 база на него. Никой не работи. Настройката вече е 8 бази, 128 връзки на процес.
Въпрос: Проблем с прехвърлянето на софтуерен лиценз 1C 8.3 на нов сървър
Добър ден.
Компанията разполагаше с един физически сървър 1C 8.3 с бази данни със счетоводни файлове. В него имаше софтуерни лицензи.
Закупени лицензи за 1c ERP:
1.на платформа за 20 души
2. към конфигурация 3. към сървър 1 s Купихме и нов rack сървър, инсталирахме платформата 1C 8.3 върху него, внедрихме ERP тестовата база данни, инсталирахме софтуерни лицензи - всичко е наред.
Имаше проблем с прехвърлянето на файлови бази данни, или по-скоро копирах самите бази данни, но при стартиране на 1C не предлага въвеждане на лиценз, но казва, че лицензът не е намерен и предлага да използвате ключ за хардуерна защита.
Кажете ми как да накарам 1C да предложи въвеждане на софтуерен лиценз за бази данни на счетоводни файлове на нов сървър?
Отговор:Супер благодаря!
Въпрос: v7: 1C 7.7 TiS - може ли да има софтуерен лиценз?
Изправен пред TiS 7.7 local без хардуерен ключ за сигурност. Доколкото си спомням, TiS 7.7 нямаше доставки с лиценз за софтуер? Спомням си, че на 7-ke имаше някои продукти с активиране според думите от книгата - трябваше да намерите дума на такава и такава страница и след това се извърши активиране, тоест без ключ за сигурност. Но изглежда, че това бяха някакви индустриални решения, доколкото си спомням. Има кутия с въпросник, дискети и книги, но никъде няма ключ. Вярно е, че няма LPT порт на компютъра, което вероятно е причината да не го инсталират навремето и да го изгубят някъде. Но все пак бих искал да се уверя, че няма TIS със софтуерно активиране, само с хардуер? Изведнъж просто винаги съм срещал хардуер преди.
Отговор: Добър ден
Сървърът има 2 софтуерни лиценза за по 20 връзки всеки. Лицензите свършиха без видима причина, въпреки че гледам през монитора на свързаните потребители - има само 19 връзки.
Как мога да разбера колко лиценза се използват. От Aladdin програмата е добра, но работи само с USB ключове.
Благодаря ти.
Отговор:
"Гледам през монитора на свързани потребители - само 19 връзки" - през кой монитор виждате издадените софтуерни лицензи?
- урок
Много компании използват 1C като основна платформа за автоматизация. Така се случи и с нас. Процесът на създаване на платформата обаче беше извършен без подходящ подход, във връзка с което първоначално имахме 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: Резултат: 1
Използване на пароли 15213 - 28875
LOCALHASP_HASPSTATUS: Номерът на версията на API е 8.0
порт номер 201
Тип ключ: HASP4 M4
LOCALHASP_HASPGENERATION: Добре, HASP4 е свързан.
LOCALHASP_HASPNETSTATUS: свързаният ключ е HASP4 Net 20
MEMOHASP_HASPID: 436444258 (десетичен), 0x1a039c62 (шестнадесетичен)LOCALHASP_ENCODEDATA: Добре.
53 C1 F1AF | 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: Резултат: 1 . Да ти кажа всичко е в реда на нещата. По-нататък се пише кой ключ е поставен.
Ако обаче има някакъв проблем, съобщението се показва по-кратко:
Това е проста демонстрационна програма за ключа HASP4
Авторско право Aladdin Knowledge Systems Ltd.LOCALHASP_ISHASP: Неуспешно: състояние = -100
Освен това всъщност няма значение какво се случва с ключа, може да не е поставен, услугата да не работи или нещо друго. Виждал съм само две LOCALHASP_ISHASP стойности досега. Това е или: Резултат: 1 или: Неуспешно: статус = -100. И второто винаги отговаряше на неработоспособност, а първото винаги означаваше, че всичко е наред. Не намерих документация за този пакет, така че не можах да разбера какви други състояния има.
Готово с ключа. Не трябва да забравяме, че вашият новоизсечен ключ ще се появи в монитора на ключовете само когато от него бъде взет поне един лиценз. След това Aladdin Monitor ще покаже информацията, която обикновено показва: това е типа ключ, броя на взетите лицензи, общия брой лицензи, кой точно е взел лиценза и времето за изчакване.
Доста лесно е да принудите това, достатъчно е ръчно да посочите нов мениджър на лицензи в клиента nethasp.ini. Но за настройката на клиента малко по-късно.
От този момент нататък първоначалната задача може да се счита за изпълнена. Сега можем да създадем няколко виртуални машини паралелно, в количество, съответстващо на броя на наличните физически ключове. Ресурси като virtualka консумират, разбира се, пени.
Проблеми и решения
Единична точка на повреда
Първият проблем, който се създава и е видим, е създаването на точка на отказ. Ако преди това ключовете са били разпределени на различни сървъри и повредата на повече от един ключ е практически изключена, тогава в този случай повредата на физическия сървър може да доведе до повреда на цялата система 1C, т.к. клиентите ще отпаднат в рамките на според мен 600 секунди и след кратко време всички ще отпаднат и няма да могат да се върнат в системата. Какво ще последва след подобен инцидент не може да се каже. Има две решения и те са насочени в различни посоки. Първото решение е да се използва конфигурация на ESX при отказ. Това обаче има смисъл, ако вашата компания вече е внедрила тази система и вече е изпълнила редица изисквания за поддържане на работоспособност в случай на повреда на който и да е компонент. Друго решение е по-тривиално:Ние създаваме група от A записи в DNS на нашата компания. Например key1, key2, key3 и така нататък. Въвеждаме DNS имена в клиенти nethasp.ini, разпространяваме файла с помощта на групова политика. Така получаваме доста гъвкава структура за достъп. В този случай, след откриване на значителен проблем с виртуалния сървър esx, можете бързо да преместите ключовете към всякакви други сървъри, вкл. към работните станции на всички служители. Успоредно с това заместваме A записи с нови. За известно време кеша на клиентите ще свърши и те отново ще могат да получат нов лиценз и да продължат да работят.
Препоръчвам да зададете обратни DNS записи за ключове, в противен случай мониторът на Аладин няма да покаже името на хоста, а ще покаже само ID на мениджъра на лицензи, което не е много удобно.
Ако вашата компания и всичко използва метод за доставка на излъчван ключ, тогава всичко е опростено и преместването на ключа към друг хост в рамките на излъчвания домейн няма да повлияе на работата ви по никакъв начин.
Ключовете падат
Има един доста често срещан проблем. Ключовете падат. Не се наблюдава обаче особена връзка. Това се случва на различни контролери, дори на различни хост системи. Когато преместих ключовете и временно ги поставих на друго място под контрола на VMware Player, ключовете често падаха. Това се изразява доста тривиално. При заявка на haspdemo се появява редът LOCALHASP_ISHASP: Failed: status = -100. Въпреки че ключът е поставен и открит. dmseg показва редове, които не са напълно разбрани: usb 2-2.1: usbfs: USBDEVFS_CONTROL неуспешно cmd aksusbd rqt 192 rq 139 len 8 ret -110Проблемът се решава толкова тривиално, колкото изглежда - чрез рестартиране на услугата. Но утайката остава и докато това не стане, сървърът няма да раздаде ключовете. Тъй като искам системата да работи безупречно, беше решено да напиша скрипт, който да възстанови самия мениджър на лицензи. И така, с помощта на приятел беше написан скрипт, който изпълнява haspdemo и се опитва да разбере дали състоянието се връща нормално или не:
[ "`haspdemo | sed -n "s/^LOCALHASP_ISHASP.* \(\-\?*\)$/\1/p"`" == "-100" ] && рестартиране на услугата haspd
Освен това, този скрипт се вмъква в стартирането на CRON всяка минута и това е всичко. Дори ако вашата система няма проблем с падането на портовете, този скрипт, мисля, няма да навреди.
Проблем с откриването на клиентски ключ
И има такъв проблем. Състои се в това, че клиентът след загуба на ключа може да не иска да вземе нов ключ. Също така този проблем може да се изрази в други прояви. Например, ако сте променили пътищата към ключовете във файла nethasp.ini, тогава клиентското приложение може доста весело да продължи да съобщава, че няма ключове и никога не ги е виждало. Ако не сте готови за такава реакция, тогава проблемът става много неприятен и започвате трескаво да проверявате работата на цялата система и да проклинате прякорите на 1C, защото всичко работи, но GlavBukh или, ако има късмет, генералът, сега не можете да влезете в 1Sku по някаква неизвестна причина и се чувствате като идиот, вместо да решите проблема бързо. Въпреки това, едно доста просто решение е помогнало досега. Необходимо е да изчистите кеша на 1C от потребителския профил. По едно време намерих отделен файл, който отговаря за тази информация, забравих кой :(Ключовете може просто да спрат да работят
Никой не е имунизиран от повреда на оборудването. И тези жалки ключове също могат да спрат да работят. И най-важното в този случай е да разберете за това възможно най-рано. За да направим това, ще използваме системата за наблюдение Zabbix. Разбира се, разполагането му само за наблюдение на ключовете е безсмислено, но ако Zabbix вече е инсталиран, тогава защо да не прикачите наблюдение на състоянието на ключовете към него.За да направим това, трябва да напишем собствен скрипт във файла с настройки на агента. Търсим конфигурационния файл на инсталирания zabbix_agent, той се нарича zabbix_agentd.conf. Отворете го и добавете линията
Потребителски параметър=hasp.status,haspdemo | grep "^LOCALHASP_ISHASP" | sed "s/^.* \(\-\?*\)$/\1/g"
Това ще позволи по команда да събере числова стойност в полето LOCALHASP_ISHASP. В самия zabbix всичко се добавя вече примитивно, ние създаваме вещза желания хост или шаблон, като Типпосочвам zabbix агент,посочете като ключов параметър hasp.статус. Тип стойност - плавам. При желание създаваме тригер, чрез който ще получите писмо или SMS, че ключът не работи. По-добре е да конфигурирате този тригер по такъв начин, че да изисква поне 2 удара и да покрива времето, необходимо за скрипта за автоматично възстановяване, описан по-горе, в противен случай ще се появят фалшиви съобщения за проблеми с ключа.
При правилни настройки, само ако ключът е напълно неработещ, ще получите известие за проблеми.
Бонус
Оказа се изненада за мен, но много хора наистина не знаят, че е възможно да принудите клиентските части на 1C да търсят ключове на определени IP адреси, използвайки TCP или UDP връзка. Наистина, много хора настройват инфраструктурата си така, че всеки излъчван домейн да има достатъчен брой ключове. Това е дивотия. За тези, които все още не знаят, ето кратко ръководство:За да контролирате достъпа до hasp ключа, на клиента има файл nethasp.ini. Той се намира в папката \conf на директорията 1C. Интересуваме се от секцията В този раздел трябва да премахнем коментарите или да създадем следните опции:
- NH_SERVER_ADDR. Тук посочваме списък с DNS имена или IP адреси на сървъри с мениджър на лицензи, разделени със запетаи.
- NH_USE_BROADCAST. Задайте стойността на Disabled.
- NH_TCPIP_METHOD. Методът по подразбиране е UDP. Можете да промените на TCP, но като цяло няма сериозна нужда от това.
Друга точка относно показването на клавиши в монитора на Aladdin. Противно на общоприетото схващане, безплатните лицензи са не само тези лицензи, които не се използват в монитора на Aladdin, но и тези, които имат 0 в полето Timeout.Стойностите обикновено изчезват в рамките на 36 часа, но лицензите все още се считат за безплатни.
Как да сканирате QR код с iPhone
Смартфон Samsung GT I8160 Galaxy Ace II: прегледи и спецификации
Как да сканирате QR код с iPhone
Всичко за услугата Zvooq за Tele2