Monitorimi i licencës së softuerit. Instalimi i veçantë i bibliotekës për botimet e mëparshme

  • tutorial

Shumë kompani përdorin 1C si platformën kryesore të automatizimit. Kështu ndodhi me ne. Megjithatë, procesi i krijimit të platformës u krye pa një qasje të duhur, në lidhje me të cilën fillimisht kishim 5 çelësa mbrojtës për 95 licenca, më pas u shfaqën 3 çelësa të tjerë fizikë për të siguruar 50 licenca të tjera klienti për 3 persona juridikë. Situata është marrëzi, pasi çdo çelës normalisht kërkon hoste të veçantë, dhe kishte gjithnjë e më pak serverë të përshtatshëm për këtë, dhe rritja e mundshme e numrit të përdoruesve dhe, rrjedhimisht, blerja e çelësave të rinj, më bëri të mendoj për një zgjidhje alternative. për të shmangur ngarkesën e panevojshme të informacionit në serverët tanë dhe në përgjithësi për ta bërë sistemin kyç më fleksibël dhe, mundësisht, më të qëndrueshëm.

Zgjedhja e sistemit

Sistemi i virtualizimit
Si sistem vizualizimi u zgjodh Esxi 5.1. Zgjedhur për mbështetje të mirë për transferimin e pajisjes USB dhe sepse, përveç ESX, kuptoj vetëm Hyper-V, i cili nuk mbështet transferimin e pajisjes.

Për të transferuar pajisjet USB në ESX, hardueri i sistemit të ftuar duhet të jetë së paku versioni 7. Më pas do të jetë e mundur të shtoni një kontrollues USB dhe të hartoni pajisjen USB në sistemin e ftuar. Ekziston edhe një pikë për mbështetjen. Zyrtarisht, VMware mbështet vetëm një listë të caktuar të pajisjeve. Dhe ai nuk është shumë i madh. Megjithatë, çelësat e zakonshëm të sigurisë të Aladdin duket se mbështeten. Lista e pajisjeve të mbështetura është në faqen zyrtare të internetit. Dhe një përshkrim i kërkesave dhe dispozitave për bllokimin e USB-së në sistemin e mysafirëve është gjithashtu në faqen zyrtare të internetit, në bazën e njohurive.

Ka mënyra alternative për të transferuar çelësat USB në një mjedis virtual dhe në atë fizik gjithashtu. Këto pajisje dhe softuer janë të ashtuquajturat USB mbi IP. Në këtë rast, produktet softuerike nuk janë shumë interesante për t'u marrë në konsideratë, por produktet e hekurit në këtë rast shfaqen mirë. Përfaqësuesi më i ndritshëm, AnywhereUSB i mirënjohur me 14 porte. Është i instaluar në një raft, ka dy ndërfaqe dhe dy hyrje të energjisë (nëse ka vërtet dy furnizime me energji, nuk e di :)). Pajisja është e mirë për të gjithë, por kushton mesatarisht 60 mijë rubla, të cilat nuk përshtateshin mirë në buxhetin tonë.

Kështu, pas testeve dhe provave, u zgjodh platforma e virtualizimit dhe u braktis përdorimi i produkteve të tjera.

Sistemi operativ dhe drejtuesit HASP

Zgjodha Debian si OS. Pse? Vetem sepse. Në fakt, në këtë konfigurim, mund të merrni çdo komplet të preferuar të shpërndarjes. Por më pëlqen gjithmonë Debian për stabilitetin dhe depon e tij të mirë.

Një paketë mjaft e njohur nga Etersoft merret si drejtues. Ju mund ta merrni paketën e përpiluar për shpërndarjen tuaj në serverin FTP të kompanisë: ftp.etersoft.ru/pub/Etersoft/HASP/stable .
Pas instalimit të paketës, shfaqet shërbimi haspd, i cili kontrollon funksionimin e dongle.

Konfigurimi dhe verifikimi

Nuk kërkon ndonjë konfigurim shtesë. Çelësi fillon të punojë pothuajse jashtë kutisë.
Ne kontrollojmë. Programi haspdemo është përfshirë për të kontrolluar funksionalitetin. Pas identifikimit të suksesshëm të çelësit dhe fillimit të punës, programi do të nxjerrë diçka të tillë në tastierë:

LOCALHASP_ISHASP: Rezultati: 1

Përdorimi i fjalëkalimeve 15213 - 28875
LOCALHASP_HASPSTATUS: Numri i versionit të API është 8.0
numri i portit 201
Lloji i çelësit: HASP4 M4
LOCALHASP_HASPGENERATION: OK, HASP4 është i lidhur.
LOCALHASP_HASPNETSTATUS: çelësi i lidhur është HASP4 Net 20
MEMOHASP_HASPID: 436444258 (decimal), 0x1a039c62 (heks)

LOCALHASP_ENCODETATA: OK.
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: Dështoi: Statusi i kthimit: 10


Fusha kryesore: LOCALHASP_ISHASP: Rezultati: 1 . Duke ju thënë se gjithçka është në rregull. Më tej shkruhet se cili çelës është futur.

Megjithatë, nëse ka ndonjë problem, atëherë mesazhi shfaqet më i shkurtër:

Ky është një program i thjeshtë demo për çelësin HASP4
E drejta e autorit Aladdin Knowledge Systems Ltd.

LOCALHASP_ISHASP: Dështoi: statusi = -100


Për më tepër, në fakt, nuk ka rëndësi se çfarë ndodh me çelësin, ai mund të mos futet, shërbimi mund të mos funksionojë ose diçka tjetër. Unë kam parë vetëm dy vlera LOCALHASP_ISHASP deri më tani. Është ose: Rezultati: 1 ose: Dështoi: statusi = -100 . Dhe kjo e fundit gjithmonë korrespondonte me mosfunksionimin, dhe e para gjithmonë nënkuptonte që gjithçka ishte në rregull. Nuk gjeta dokumentacion për këtë paketë, ndaj nuk munda të zbuloja se çfarë statusesh të tjera ka.

Mbaroi me çelësin. Nuk duhet të harrojmë se çelësi juaj i sapokrijuar do të shfaqet në monitorin e çelësave vetëm kur të merret të paktën një licencë prej tij. Më pas monitori aladdin do të tregojë informacionin që tregon zakonisht: ky është lloji i çelësit, numri i licencave të marra, licencat totale, kush e ka marrë saktësisht licencën dhe afatin.
Është mjaft e thjeshtë ta detyrosh këtë, mjafton të specifikosh manualisht një menaxher të ri licence në klientin nethasp.ini. Por për vendosjen e klientit pak më vonë.

Nga ky moment, detyra fillestare mund të konsiderohet e përfunduar. Tani mund të krijojmë disa makina virtuale paralelisht, në një sasi që korrespondon me numrin e çelësave fizikë të disponueshëm. Burimet e tilla virtualka konsumojnë, natyrisht, qindarkë.

Problemet dhe Zgjidhjet

Pika e vetme e dështimit
Problemi i parë që krijohet dhe në pamje të qartë është krijimi i një pike dështimi. Nëse më parë çelësat shpërndaheshin në serverë të ndryshëm dhe dështimi i më shumë se një çelësi praktikisht përjashtohet, atëherë në këtë rast dështimi i serverit fizik mund të çojë në dështimin e të gjithë sistemit 1C, sepse. klientët do të bien brenda, për mendimin tim, brenda 600 sekondave dhe pas një kohe të shkurtër të gjithë do të bien dhe nuk do të mund të kthehen në sistem. Nuk mund të thuhet se çfarë do të pasojë një incident i tillë. Ka dy zgjidhje dhe ato drejtohen në drejtime të ndryshme. Zgjidhja e parë është përdorimi i një konfigurimi ESX të dështimit. Sidoqoftë, kjo ka kuptim nëse kompania juaj e ka vendosur tashmë këtë sistem dhe ka përmbushur tashmë një numër kërkesash për të ruajtur funksionimin në rast të dështimit të ndonjë komponenti. Një zgjidhje tjetër është më e parëndësishme:
Ne krijojmë një grup regjistrimesh A në DNS të kompanisë sonë. Për shembull, çelësi1, çelësi2, çelësi3 dhe kështu me radhë. Ne futim emrat DNS në klientët nethasp.ini, shpërndajmë skedarin duke përdorur politikën e grupit. Kështu, marrim një strukturë aksesi mjaft fleksibël. Në këtë rast, pasi të zbuloni një problem të rëndësishëm me serverin virtual esx, mund t'i zhvendosni shpejt çelësat në çdo server tjetër, përfshirë. në stacionet e punës të çdo punonjësi. Paralelisht, ne zëvendësojmë rekordet A me të reja. Për ca kohë, cache-i i klientëve do të mbarojë dhe ata përsëri do të jenë në gjendje të marrin një licencë të re dhe të vazhdojnë të punojnë.
Unë rekomandoj të vendosni rekorde të kundërta DNS për çelësat, përndryshe monitori aladdin nuk do të tregojë emrin e hostit, por do të tregojë vetëm ID-në e menaxherit të licencës, gjë që nuk është shumë e përshtatshme.
Nëse kompania juaj dhe gjithçka përdor një metodë të shpërndarjes së çelësit të transmetimit, atëherë gjithçka thjeshtohet dhe zhvendosja e çelësit në një host tjetër brenda domenit të transmetimit nuk do të ndikojë në asnjë mënyrë në punën tuaj.
Bien çelësat
Ekziston një problem mjaft i zakonshëm. Bien çelësat. Megjithatë, asnjë lidhje e veçantë nuk u vërejt. Kjo ndodh në kontrollues të ndryshëm, madje edhe në sisteme të ndryshme pritës. Kur i zhvendosa çelësat dhe i vendosa përkohësisht në një vend tjetër nën kontrollin e VMware Player, çelësat binin shpesh. Kjo shprehet në mënyrë të parëndësishme. Kur kërkoni haspdemo, shfaqet rreshti LOCALHASP_ISHASP: Dështoi: status = -100. Edhe pse çelësi është futur dhe zbuluar. dmseg tregon linja që nuk kuptohen plotësisht: usb 2-2.1: usbfs: USBDEVFS_CONTROL dështoi cmd aksusbd rqt 192 rq 139 len 8 ret -110
Problemi zgjidhet aq i parëndësishëm sa duket - duke rifilluar shërbimin. Por sedimenti mbetet dhe derisa të bëhet kjo, serveri nuk do të shpërndajë çelësat. Meqenëse unë dua që sistemi të funksionojë pa të meta, u vendos të shkruaj një skenar që do të rivendoste vetë menaxherin e licencës. Pra, me ndihmën e një miku, u shkrua një skript që ekzekuton haspdemo dhe përpiqet të kuptojë nëse statusi po kthehet normal apo jo:
[ "`haspdemo | sed -n "s/^LOCALHASP_ISHASP.* \(\-\?*\)$/\1/p"`" == "-100" ] && shërbimi haspd rinis
Më tej, ky skenar futet në lëshimin e CRON çdo minutë dhe kaq. Edhe nëse sistemi juaj nuk e ka problemin e rënies së porteve, ky skenar, mendoj se nuk do të dëmtojë.
Problemi i zbulimit të çelësit të klientit
Dhe ekziston një problem i tillë. Ai konsiston në faktin se klienti, pas humbjes së çelësit, mund të mos dëshirojë të marrë një çelës të ri. Gjithashtu, ky problem mund të shprehet në manifestime të tjera. Për shembull, nëse keni ndryshuar shtigjet për çelësat në skedarin nethasp.ini, atëherë aplikacioni i klientit mund të vazhdojë me shumë gëzim të raportojë se nuk ka çelësa dhe nuk i ka parë kurrë. Nëse nuk jeni gati për një reagim të tillë, atëherë problemi bëhet shumë i pakëndshëm dhe filloni të kontrolloni furishëm funksionimin e të gjithë sistemit dhe të shani pseudonimet 1C, sepse gjithçka funksionon, por GlavBukh ose, siç do ta kishte fat, Gjenerali, tani nuk mund të hyni në 1Sku për ndonjë arsye të panjohur dhe ju ndiheni si një idiot në vend që ta rregulloni problemin shpejt. Sidoqoftë, një zgjidhje mjaft e thjeshtë ka ndihmuar deri më tani. Është e nevojshme të pastroni cache 1C nga profili i përdoruesit. Në një kohë, gjeta një skedar të veçantë që është përgjegjës për këtë informacion, harrova se cilin :(
Çelësat thjesht mund të ndalojnë së punuari
Askush nuk është i imunizuar nga dështimi i pajisjeve. Dhe këta çelësa patetikë mund të ndalojnë së punuari gjithashtu. Dhe gjëja më e rëndësishme në këtë rast është ta zbuloni sa më shpejt që të jetë e mundur. Për ta bërë këtë, ne do të përdorim sistemin e monitorimit Zabbix. Sigurisht, vendosja e tij vetëm për monitorimin e çelësave është e kotë, por nëse Zabbix është instaluar tashmë, atëherë pse të mos bashkëngjitni monitorimin e gjendjes së çelësave në të.
Për ta bërë këtë, ne duhet të shkruajmë skriptin tonë në skedarin e cilësimeve të agjentit. Ne po kërkojmë skedarin e konfigurimit të zabbix_agent të instaluar, ai quhet zabbix_agentd.conf. Hapeni dhe shtoni rreshtin
UserParameter=hasp.status,haspdemo | grep "^LOCALHASP_ISHASP" | sed "s/^.* \(\-\?*\)$/\1/g"

Kjo do të lejojë komandën të mbledhë një vlerë numerike në fushën LOCALHASP_ISHASP. Në vetë zabbix, gjithçka është shtuar tashmë në mënyrë primitive, ne krijojmë artikull për hostin ose shabllonin e dëshiruar, si lloji tregojnë agjenti zabbix, specifikoni si parametër kyç hasp.statusi. Lloji i vlerës - noton. Nëse dëshironi, ne krijojmë një shkas me të cilin do të merrni një letër ose SMS që çelësi nuk funksionon. Është më mirë ta konfiguroni këtë shkas në atë mënyrë që të kërkojë të paktën 2 goditje dhe të mbulojë kohën e kërkuar nga skripti i rikuperimit automatik i përshkruar më sipër, përndryshe do të shfaqen mesazhe të rreme për problemet me çelësin.
Me cilësimet e sakta, vetëm nëse çelësi nuk funksionon plotësisht, do të merrni një njoftim për problemet.

Bonus

Doli të ishte një surprizë për mua, por shumë njerëz me të vërtetë nuk e dinë se është e mundur të detyrohen pjesët e klientit 1C të kërkojnë çelësa në adresat IP të specifikuara duke përdorur një lidhje TCP ose UDP. Në të vërtetë, shumë njerëz vendosin infrastrukturën e tyre në mënyrë që çdo domen transmetimi të ketë një numër të mjaftueshëm çelësash. Kjo është egërsi. Për ata që nuk e dinë ende, këtu është një udhëzues i shpejtë:
Për të kontrolluar aksesin në çelësin hasp, ekziston një skedar nethasp.ini në klient. Ndodhet në dosjen \conf të drejtorisë 1C. Ne jemi të interesuar për seksionin Në këtë seksion, ne duhet të çkomentojmë ose të krijojmë opsionet e mëposhtme:
  • NH_SERVER_ADDR. Këtu ne specifikojmë një listë të emrave DNS ose adresave IP të serverëve me një menaxher licence të ndarë me presje.
  • NH_USE_BROADCAST. Vendosni vlerën në Disabled.
  • NH_TCPIP_METHOD. Metoda e parazgjedhur është UDP. Ju mund të ndryshoni në TCP, por në përgjithësi nuk ka nevojë serioze për këtë.

Një pikë tjetër në lidhje me shfaqjen e çelësave në monitorin aladdin. Në kundërshtim me besimin popullor, licencat falas nuk janë vetëm ato licenca që nuk përdoren në monitorin aladdin, por edhe ato që kanë 0 në fushën Timeout. Vlerat zakonisht zhduken brenda 36 orëve, por licencat ende konsiderohen të lira.

Në përfundim
Mendova për një kohë të gjatë nëse ka ndonjë pikë në një artikull të tillë, në fund të fundit, e gjithë kjo mund të gjendet në internet, megjithatë, duke pasur parasysh kohën që kalova vetë për të mbledhur të gjitha informacionet, mendova se do të ishte shumë mirë nëse të paktën dikush këtë Artikulli do të jetë i dobishëm dhe do të kursejë kohë.

Pyetje: Monitorimi i licencave të softuerit


Mirembrema.
Windows Server 2008 + Server SQL + Server 1C 8.2.
Licencat e softuerit janë instaluar në server 10 copë + 5 copë = 15 copë.
Numri maksimal i përdoruesve që punojnë njëkohësisht - 13 copë.
Baza është një. Prandaj, përdoruesit ekzekutojnë vetëm një shembull të programit.
Ndonjëherë disa përdorues nuk mund të futin 1s (çelësi i mbrojtjes së programit nuk u gjet). Doli rastësisht që përdoruesit mund të identifikohen përsëri nëse një përdorues i veçantë rinis 1s-ku. Prandaj, siç e kuptoj unë, ky përdorues shpenzon më shumë se një licencë gjatë punës së tij.
Pyetje: si të gjurmoni cilat licenca ku shkuan dhe si të merreni me licenca të tilla të ngrira?

Përgjigje:

Përpunim i bukur, shumë i nevojshëm! Por nuk funksionon)
(ExternalProcessing.MonitoringLicenses.ObjectModule(53)): (ExternalProcessing.MonitoringLicenses.ObjectModule(23)): Gabim në thirrjen e konstruktorit (COMObject): -2147221005(0x800401F3): Varg i pavlefshëm i klasës
ThrowException DescriptionError();

Ndoshta dikush mund ta rregullojë atë?

Pyetje: Problem me licencat e softuerit në serverin 1c


Përshëndetje të dashur përdorues të forumit! Ju lutem më tregoni nëse dikush ka hasur se si të jetë në një situatë të tillë.
Fillimisht: ekzistonte një skedar bazë 1s KA 1.1, 1s 8.2, platforma 8.2.19.130, skedar në serverin e terminalit. Në vetë serverin, u instalua një çelës për 10 licenca përdoruesi dhe 5 licenca softuerësh (skedari i licencës ishte në C:\ProgramData\1C\1Cv82\conf). Përdoruesit punuan përmes sesioneve të terminalit.
U bë: transferuar në versionin klient-server (server 1s x64, platforma 8.3.8.2054), Postgres subd, përdoruesit punojnë drejtpërdrejt nga vendet e tyre të punës. Kompjuterët marrin një licencë përmes rrjetit nga një server.
Problemi është se serveri 1s nuk i sheh licencat e softuerit. Skedari i licencës u kopjua në dosjen e serverit conf (C:\Program Files\1cv8\conf), në dosjen e licencave (C:\Program Files\1cv8\8.3.8.2054\licenses - megjithëse e kuptoj që licenca nuk duhet të jetë të ruajtura këtu), dhe gjithashtu në dosjen e platformës përgjatë të njëjtave shtigje (C:\Program Files (x86)\1cv8\conf, C:\Program Files (x86)\1cv8\8.3.8.2054\licensat).
Me sa kam lexuar në internet, çelësat e softuerit kërkohen dhe merren në radhë të parë, kështu që duhet të funksionojë ...
Por mendimet e trishtuara më vizitojnë se kur instaloni një licencë softueri për 5 përdorues, diçka "qepur" në regjistër, që e lidh atë me skemën origjinale, në 1s 8.2 dhe që serveri 8.3 nuk e sheh. Meqenëse do t'ju duhet të aktivizoni një kod të ri pin në licencën e softuerit, ju lutem më ndihmoni, më tregoni nëse është vërtet kështu??

Përgjigje:

Kur aktivizoni licencat e softuerit, krijohen më shumë se një skedar. Më e mira është të shkruash në adresë, më janë përgjigjur brenda gjysmë ore për çështjen e çaktivizimit të licencës. Ata sugjeruan gjetjen dhe fshirjen e të gjithë skedarëve 2*.lic dhe të gjithë skedarëve conn8211.pfl (ose 1Сv8conn.pfl nëse versioni 8.3). Prandaj, të paktën ju duhet të zhvendosni të gjithë këta skedarë, por askush nuk do të thotë nëse do të ndihmojë, kështu që unë do t'u shkruaja atyre një letër. Për shkak të veprimeve të pasakta, paketa e licencës mund të jetë në listën e zezë.

Pyetje: Licenca e softuerit dhe lidhja COM


Është instaluar një licencë softueri.
Kur përpiqem të nis 1C përmes një lidhjeje Com, ai thotë:
-----------
Nuk u gjet asnjë licencë falas!
Gjetja e licencave te klienti:
Gabim në licencimin e softuerit
Është tejkaluar numri maksimal i përdoruesve të lejuar nga skedari i licencës së softuerit.
Burimi: V82.COMConnector.1
-----------
Cili është problemi?

Përgjigje:Është tejkaluar numri maksimal i përdoruesve të lejuar nga skedari i licencës së softuerit.

Pyetje: Si mund të zbuloj se cili skedar (.lic) korrespondon me cilën licencë softueri?


Përshëndetje. Ka dy licenca softuerike të instaluara në server (duhet të instalohen). Por shoh që shpërndahet vetëm një. Në C:\Users\1C_admin.1C8\AppData\Local\1C\1cv82\conf ka 3 skedarë: 2014*****.lic në njërin prej tyre, nëse e hapni përmes një shikuesi teksti, ai shkruhet në në krye (vetë licencat e softuerit janë të numëruar 8100** ***):

Server1 përdor dy kopje të të njëjtit skedar licence softueri: file://C:/ProgramData/1C/1Cv82/conf/2014*****.lic dhe file://C:/Users/1C_admin.1C8 /AppData/ Local/1C/1Cv82/conf/2014*****.lic

Edhe pse kjo dosje është bosh.
Dosja C:\Users\All Users\1C\1Cv82\conf është gjithashtu bosh.
A mund të hiqet ky mbishkrim atëherë do të fillojë të dëgjohet gjithçka?

Dhe më e rëndësishmja, shikoj përmes tastierës së administrimit, serveri kryesor 8100 është një çelës softuerësh. Dhe cili është çelësi ORGL8 Set 20 - cili është ky çelës? Software apo harduer? Unë mendoj se softueri, por pse atëherë Serveri dhe jo klienti?

Përgjigje:

Askush nuk di se si të zbulojë se çfarë licence është nga skedari .lic (korrespondon me numrin e licencës.lic nga karta e regjistrimit)?

Pyetje: Truket e lëshimit të licencave të softuerit nga serveri 1C


Pershendetje te gjitheve!
Miq, ju lutem me tregoni per licencat, ka disa gjera qe nuk me jane te qarta.
Një licencë softuerike për 10 përdorues aktivizohet në server. Serveri ka një server 1C, një bazë të dhënash SQL dhe një server terminal.
Lëshimi i licencave ndodh si më poshtë (ndoshta kjo nuk është e saktë, e saktë nëse nuk është e drejtë).
1. Nëse një përdorues ka një platformë në kompjuterin e tij lokal dhe ai lidhet me bazën e të dhënave 1c në server përmes rrjetit, atëherë për çdo shembull ekzekutues të programit, serveri i jep atij një licencë. Kjo do të thotë, nëse një përdorues lëshon 10 baza të të dhënave, atëherë nuk do të ketë licenca në server.
2. Nëse përdoruesi lidhet nëpërmjet RDP, atëherë serveri i jep atij një licencë klienti dhe përdoruesi do të jetë në gjendje të ekzekutojë një numër të pakufizuar instancash (bazash) programi.
Pyetja kryesore është, a do të funksionojë pika e dytë nëse përdoruesi lidhet me serverin e terminalit përmes RDP, licencat e softuerit do të aktivizohen atje, por nuk do të ketë server 1c? Në terminal, ai do të ketë një platformë, por pa një server 1c. Nëse është e detyrueshme që artikulli dy të funksionojë, në serverin e terminaleve duhet të ketë server 1s?

Përgjigje:

lëshimi i tillë i licencave funksionon me çdo nisje lokale të 1C (RDP është një lëshim lokal) nëse licenca nuk shpërndahet nga serveri 1C

Pyetje: Licencat e softuerit të klientit nuk shpërndahen


Mirembrema.

Krijoi një grup 1C (8.3.7.1759) dhe një server licencimi. Veproi sipas këtij udhëzimi. (). Aktivizoi një licencë softueri me shumë përdorues në serverin e licencës. Nëse e drejtoj klientin 1C direkt në serverin e licencimit, atëherë ai zakonisht merr një licencë softueri. Nga çdo vend tjetër, nëse lidhemi me bazën në këtë grup, lëshohet një licencë harduerike. Skedari i licencës ndodhet këtu C:\ProgramData\1C\licenses

Përgjigje:

Ka akses për lexim. Funksionaliteti i caktimit u shtua në serverin e licencimit. Kutia e zgjedhjes për të përdorur një çelës hardueri nuk ia vlen .. Dhe ende merr një licencë hekuri ...
--- Bashkoni mesazhet, 28 dhjetor 2015 ---

Okarlov tha:

Kontrollo një gabim tjetër të regjistruar

Nëse vetitë e serverit të punës të grupit vendosin një kufi në numrin e bazave të informacionit për proces punonjës, atëherë ky server mund të fillojë të shpërndajë funksione që ndalohen nga kërkesat për caktimin e funksionalitetit.

Klikoni për të zbuluar...

Grupi është i ri - ka vetëm 1 bazë në të deri më tani. Askush nuk punon. Konfigurimi tani është 8 baza, 128 lidhje për proces.

Pyetje: Problem me transferimin e një licence softueri 1C 8.3 në një server të ri


Mirembrema.

Kompania kishte një server fizik 1C 8.3 me bazat e të dhënave të skedarëve të kontabilitetit. Kishte licenca softuerike në të.

Licencat e blera për 1c ERP:

1.për platformë për 20 persona
2. te konfigurimi 3. te serveri 1 s Ne gjithashtu blemë një server të ri raft, instaluam platformën 1C 8.3 në të, vendosëm bazën e të dhënave të testit ERP, instaluam licencat e softuerit - gjithçka është në rregull.

Kishte një problem me transferimin e bazave të të dhënave të skedarëve, ose më saktë, unë kopjova vetë bazat e të dhënave, por kur nis 1C, nuk ofron të futësh një licencë, por thotë që licenca nuk u gjet dhe sugjeron përdorimin e një çelësi mbrojtjeje harduerike.

Më tregoni se si ta bëj 1C të sugjerojë prezantimin e një licence softueri për bazat e të dhënave të skedarëve të kontabilitetit në një server të ri?

Përgjigje: Super faleminderit!

Pyetje: v7: 1C 7.7 TiS - a mund të ketë një licencë softueri?


U përball me TiS 7.7 lokal pa një çelës sigurie harduerike. Me sa mbaj mend, TiS 7.7 nuk kishte dërgesa me licencë softueri? Mbaj mend që në 7-ke kishte disa produkte me aktivizim sipas fjalëve nga libri - duhej të gjeje një fjalë në filan faqe dhe pastaj u bë aktivizimi, domethënë pa çelës sigurie. Por duket se këto ishin disa vendime të industrisë, me sa mbaj mend. Ka një kuti me një pyetësor, disqe dhe libra, por nuk ka asnjë çelës askund. Vërtetë, nuk ka asnjë port LPT në PC, kjo është ndoshta arsyeja pse ata nuk e instaluan atë në atë kohë dhe e humbën atë diku. Por prapëseprapë, do të doja të sigurohesha që nuk kishte TIS me aktivizimin e softuerit, vetëm me harduer? Papritur, thjesht kam hasur gjithmonë pajisje më parë.

Përgjigje:

Mirembrema
Serveri ka 2 licenca softuerike për 20 lidhje secila. Licencat mbaruan pa asnjë arsye të dukshme, megjithëse shikoj përmes monitorit të përdoruesve të lidhur - ka vetëm 19 lidhje.
Si mund të zbuloj se sa licenca janë në përdorim. Nga Aladdin, programi është i mirë, por funksionon vetëm me çelësa USB.
Faleminderit.

Përgjigje:

"Unë shikoj përmes monitorit të përdoruesve të lidhur - vetëm 19 lidhje" - përmes cilit monitor i shihni licencat e lëshuara të softuerit?
  • tutorial

Shumë kompani përdorin 1C si platformën kryesore të automatizimit. Kështu ndodhi me ne. Megjithatë, procesi i krijimit të platformës u krye pa një qasje të duhur, në lidhje me të cilën fillimisht kishim 5 çelësa mbrojtës për 95 licenca, më pas u shfaqën 3 çelësa të tjerë fizikë për të siguruar 50 licenca të tjera klienti për 3 persona juridikë. Situata është marrëzi, pasi çdo çelës normalisht kërkon hoste të veçantë, dhe kishte gjithnjë e më pak serverë të përshtatshëm për këtë, dhe rritja e mundshme e numrit të përdoruesve dhe, rrjedhimisht, blerja e çelësave të rinj, më bëri të mendoj për një zgjidhje alternative. për të shmangur ngarkesën e panevojshme të informacionit në serverët tanë dhe në përgjithësi për ta bërë sistemin kyç më fleksibël dhe, mundësisht, më të qëndrueshëm.

Zgjedhja e sistemit

Sistemi i virtualizimit
Si sistem vizualizimi u zgjodh Esxi 5.1. Zgjedhur për mbështetje të mirë për transferimin e pajisjes USB dhe sepse, përveç ESX, kuptoj vetëm Hyper-V, i cili nuk mbështet transferimin e pajisjes.

Për të transferuar pajisjet USB në ESX, hardueri i sistemit të ftuar duhet të jetë së paku versioni 7. Më pas do të jetë e mundur të shtoni një kontrollues USB dhe të hartoni pajisjen USB në sistemin e ftuar. Ekziston edhe një pikë për mbështetjen. Zyrtarisht, VMware mbështet vetëm një listë të caktuar të pajisjeve. Dhe ai nuk është shumë i madh. Megjithatë, çelësat e zakonshëm të sigurisë të Aladdin duket se mbështeten. Lista e pajisjeve të mbështetura është në faqen zyrtare të internetit. Dhe një përshkrim i kërkesave dhe dispozitave për bllokimin e USB-së në sistemin e mysafirëve është gjithashtu në faqen zyrtare të internetit, në bazën e njohurive.

Ka mënyra alternative për të transferuar çelësat USB në një mjedis virtual dhe në atë fizik gjithashtu. Këto pajisje dhe softuer janë të ashtuquajturat USB mbi IP. Në këtë rast, produktet softuerike nuk janë shumë interesante për t'u marrë në konsideratë, por produktet e hekurit në këtë rast shfaqen mirë. Përfaqësuesi më i ndritshëm, AnywhereUSB i mirënjohur me 14 porte. Është i instaluar në një raft, ka dy ndërfaqe dhe dy hyrje të energjisë (nëse ka vërtet dy furnizime me energji, nuk e di :)). Pajisja është e mirë për të gjithë, por kushton mesatarisht 60 mijë rubla, të cilat nuk përshtateshin mirë në buxhetin tonë.

Kështu, pas testeve dhe provave, u zgjodh platforma e virtualizimit dhe u braktis përdorimi i produkteve të tjera.

Sistemi operativ dhe drejtuesit HASP

Zgjodha Debian si OS. Pse? Vetem sepse. Në fakt, në këtë konfigurim, mund të merrni çdo komplet të preferuar të shpërndarjes. Por më pëlqen gjithmonë Debian për stabilitetin dhe depon e tij të mirë.

Një paketë mjaft e njohur nga Etersoft merret si drejtues. Ju mund ta merrni paketën e përpiluar për shpërndarjen tuaj në serverin FTP të kompanisë: ftp.etersoft.ru/pub/Etersoft/HASP/stable .
Pas instalimit të paketës, shfaqet shërbimi haspd, i cili kontrollon funksionimin e dongle.

Konfigurimi dhe verifikimi

Nuk kërkon ndonjë konfigurim shtesë. Çelësi fillon të punojë pothuajse jashtë kutisë.
Ne kontrollojmë. Programi haspdemo është përfshirë për të kontrolluar funksionalitetin. Pas identifikimit të suksesshëm të çelësit dhe fillimit të punës, programi do të nxjerrë diçka të tillë në tastierë:

LOCALHASP_ISHASP: Rezultati: 1

Përdorimi i fjalëkalimeve 15213 - 28875
LOCALHASP_HASPSTATUS: Numri i versionit të API është 8.0
numri i portit 201
Lloji i çelësit: HASP4 M4
LOCALHASP_HASPGENERATION: OK, HASP4 është i lidhur.
LOCALHASP_HASPNETSTATUS: çelësi i lidhur është HASP4 Net 20
MEMOHASP_HASPID: 436444258 (decimal), 0x1a039c62 (heks)

LOCALHASP_ENCODETATA: OK.
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: Dështoi: Statusi i kthimit: 10


Fusha kryesore: LOCALHASP_ISHASP: Rezultati: 1 . Duke ju thënë se gjithçka është në rregull. Më tej shkruhet se cili çelës është futur.

Megjithatë, nëse ka ndonjë problem, atëherë mesazhi shfaqet më i shkurtër:

Ky është një program i thjeshtë demo për çelësin HASP4
E drejta e autorit Aladdin Knowledge Systems Ltd.

LOCALHASP_ISHASP: Dështoi: statusi = -100


Për më tepër, në fakt, nuk ka rëndësi se çfarë ndodh me çelësin, ai mund të mos futet, shërbimi mund të mos funksionojë ose diçka tjetër. Unë kam parë vetëm dy vlera LOCALHASP_ISHASP deri më tani. Është ose: Rezultati: 1 ose: Dështoi: statusi = -100 . Dhe kjo e fundit gjithmonë korrespondonte me mosfunksionimin, dhe e para gjithmonë nënkuptonte që gjithçka ishte në rregull. Nuk gjeta dokumentacion për këtë paketë, ndaj nuk munda të zbuloja se çfarë statusesh të tjera ka.

Mbaroi me çelësin. Nuk duhet të harrojmë se çelësi juaj i sapokrijuar do të shfaqet në monitorin e çelësave vetëm kur të merret të paktën një licencë prej tij. Më pas monitori aladdin do të tregojë informacionin që tregon zakonisht: ky është lloji i çelësit, numri i licencave të marra, licencat totale, kush e ka marrë saktësisht licencën dhe afatin.
Është mjaft e thjeshtë ta detyrosh këtë, mjafton të specifikosh manualisht një menaxher të ri licence në klientin nethasp.ini. Por për vendosjen e klientit pak më vonë.

Nga ky moment, detyra fillestare mund të konsiderohet e përfunduar. Tani mund të krijojmë disa makina virtuale paralelisht, në një sasi që korrespondon me numrin e çelësave fizikë të disponueshëm. Burimet e tilla virtualka konsumojnë, natyrisht, qindarkë.

Problemet dhe Zgjidhjet

Pika e vetme e dështimit
Problemi i parë që krijohet dhe në pamje të qartë është krijimi i një pike dështimi. Nëse më parë çelësat shpërndaheshin në serverë të ndryshëm dhe dështimi i më shumë se një çelësi praktikisht përjashtohet, atëherë në këtë rast dështimi i serverit fizik mund të çojë në dështimin e të gjithë sistemit 1C, sepse. klientët do të bien brenda, për mendimin tim, brenda 600 sekondave dhe pas një kohe të shkurtër të gjithë do të bien dhe nuk do të mund të kthehen në sistem. Nuk mund të thuhet se çfarë do të pasojë një incident i tillë. Ka dy zgjidhje dhe ato drejtohen në drejtime të ndryshme. Zgjidhja e parë është përdorimi i një konfigurimi ESX të dështimit. Sidoqoftë, kjo ka kuptim nëse kompania juaj e ka vendosur tashmë këtë sistem dhe ka përmbushur tashmë një numër kërkesash për të ruajtur funksionimin në rast të dështimit të ndonjë komponenti. Një zgjidhje tjetër është më e parëndësishme:
Ne krijojmë një grup regjistrimesh A në DNS të kompanisë sonë. Për shembull, çelësi1, çelësi2, çelësi3 dhe kështu me radhë. Ne futim emrat DNS në klientët nethasp.ini, shpërndajmë skedarin duke përdorur politikën e grupit. Kështu, marrim një strukturë aksesi mjaft fleksibël. Në këtë rast, pasi të zbuloni një problem të rëndësishëm me serverin virtual esx, mund t'i zhvendosni shpejt çelësat në çdo server tjetër, përfshirë. në stacionet e punës të çdo punonjësi. Paralelisht, ne zëvendësojmë rekordet A me të reja. Për ca kohë, cache-i i klientëve do të mbarojë dhe ata përsëri do të jenë në gjendje të marrin një licencë të re dhe të vazhdojnë të punojnë.
Unë rekomandoj të vendosni rekorde të kundërta DNS për çelësat, përndryshe monitori aladdin nuk do të tregojë emrin e hostit, por do të tregojë vetëm ID-në e menaxherit të licencës, gjë që nuk është shumë e përshtatshme.
Nëse kompania juaj dhe gjithçka përdor një metodë të shpërndarjes së çelësit të transmetimit, atëherë gjithçka thjeshtohet dhe zhvendosja e çelësit në një host tjetër brenda domenit të transmetimit nuk do të ndikojë në asnjë mënyrë në punën tuaj.
Bien çelësat
Ekziston një problem mjaft i zakonshëm. Bien çelësat. Megjithatë, asnjë lidhje e veçantë nuk u vërejt. Kjo ndodh në kontrollues të ndryshëm, madje edhe në sisteme të ndryshme pritës. Kur i zhvendosa çelësat dhe i vendosa përkohësisht në një vend tjetër nën kontrollin e VMware Player, çelësat binin shpesh. Kjo shprehet në mënyrë të parëndësishme. Kur kërkoni haspdemo, shfaqet rreshti LOCALHASP_ISHASP: Dështoi: status = -100. Edhe pse çelësi është futur dhe zbuluar. dmseg tregon linja që nuk kuptohen plotësisht: usb 2-2.1: usbfs: USBDEVFS_CONTROL dështoi cmd aksusbd rqt 192 rq 139 len 8 ret -110
Problemi zgjidhet aq i parëndësishëm sa duket - duke rifilluar shërbimin. Por sedimenti mbetet dhe derisa të bëhet kjo, serveri nuk do të shpërndajë çelësat. Meqenëse unë dua që sistemi të funksionojë pa të meta, u vendos të shkruaj një skenar që do të rivendoste vetë menaxherin e licencës. Pra, me ndihmën e një miku, u shkrua një skript që ekzekuton haspdemo dhe përpiqet të kuptojë nëse statusi po kthehet normal apo jo:
[ "`haspdemo | sed -n "s/^LOCALHASP_ISHASP.* \(\-\?*\)$/\1/p"`" == "-100" ] && shërbimi haspd rinis
Më tej, ky skenar futet në lëshimin e CRON çdo minutë dhe kaq. Edhe nëse sistemi juaj nuk e ka problemin e rënies së porteve, ky skenar, mendoj se nuk do të dëmtojë.
Problemi i zbulimit të çelësit të klientit
Dhe ekziston një problem i tillë. Ai konsiston në faktin se klienti, pas humbjes së çelësit, mund të mos dëshirojë të marrë një çelës të ri. Gjithashtu, ky problem mund të shprehet në manifestime të tjera. Për shembull, nëse keni ndryshuar shtigjet për çelësat në skedarin nethasp.ini, atëherë aplikacioni i klientit mund të vazhdojë me shumë gëzim të raportojë se nuk ka çelësa dhe nuk i ka parë kurrë. Nëse nuk jeni gati për një reagim të tillë, atëherë problemi bëhet shumë i pakëndshëm dhe filloni të kontrolloni furishëm funksionimin e të gjithë sistemit dhe të shani pseudonimet 1C, sepse gjithçka funksionon, por GlavBukh ose, siç do ta kishte fat, Gjenerali, tani nuk mund të hyni në 1Sku për ndonjë arsye të panjohur dhe ju ndiheni si një idiot në vend që ta rregulloni problemin shpejt. Sidoqoftë, një zgjidhje mjaft e thjeshtë ka ndihmuar deri më tani. Është e nevojshme të pastroni cache 1C nga profili i përdoruesit. Në një kohë, gjeta një skedar të veçantë që është përgjegjës për këtë informacion, harrova se cilin :(
Çelësat thjesht mund të ndalojnë së punuari
Askush nuk është i imunizuar nga dështimi i pajisjeve. Dhe këta çelësa patetikë mund të ndalojnë së punuari gjithashtu. Dhe gjëja më e rëndësishme në këtë rast është ta zbuloni sa më shpejt që të jetë e mundur. Për ta bërë këtë, ne do të përdorim sistemin e monitorimit Zabbix. Sigurisht, vendosja e tij vetëm për monitorimin e çelësave është e kotë, por nëse Zabbix është instaluar tashmë, atëherë pse të mos bashkëngjitni monitorimin e gjendjes së çelësave në të.
Për ta bërë këtë, ne duhet të shkruajmë skriptin tonë në skedarin e cilësimeve të agjentit. Ne po kërkojmë skedarin e konfigurimit të zabbix_agent të instaluar, ai quhet zabbix_agentd.conf. Hapeni dhe shtoni rreshtin
UserParameter=hasp.status,haspdemo | grep "^LOCALHASP_ISHASP" | sed "s/^.* \(\-\?*\)$/\1/g"

Kjo do të lejojë komandën të mbledhë një vlerë numerike në fushën LOCALHASP_ISHASP. Në vetë zabbix, gjithçka është shtuar tashmë në mënyrë primitive, ne krijojmë artikull për hostin ose shabllonin e dëshiruar, si lloji tregojnë agjenti zabbix, specifikoni si parametër kyç hasp.statusi. Lloji i vlerës - noton. Nëse dëshironi, ne krijojmë një shkas me të cilin do të merrni një letër ose SMS që çelësi nuk funksionon. Është më mirë ta konfiguroni këtë shkas në atë mënyrë që të kërkojë të paktën 2 goditje dhe të mbulojë kohën e kërkuar nga skripti i rikuperimit automatik i përshkruar më sipër, përndryshe do të shfaqen mesazhe të rreme për problemet me çelësin.
Me cilësimet e sakta, vetëm nëse çelësi nuk funksionon plotësisht, do të merrni një njoftim për problemet.

Bonus

Doli të ishte një surprizë për mua, por shumë njerëz me të vërtetë nuk e dinë se është e mundur të detyrohen pjesët e klientit 1C të kërkojnë çelësa në adresat IP të specifikuara duke përdorur një lidhje TCP ose UDP. Në të vërtetë, shumë njerëz vendosin infrastrukturën e tyre në mënyrë që çdo domen transmetimi të ketë një numër të mjaftueshëm çelësash. Kjo është egërsi. Për ata që nuk e dinë ende, këtu është një udhëzues i shpejtë:
Për të kontrolluar aksesin në çelësin hasp, ekziston një skedar nethasp.ini në klient. Ndodhet në dosjen \conf të drejtorisë 1C. Ne jemi të interesuar për seksionin Në këtë seksion, ne duhet të çkomentojmë ose të krijojmë opsionet e mëposhtme:
  • NH_SERVER_ADDR. Këtu ne specifikojmë një listë të emrave DNS ose adresave IP të serverëve me një menaxher licence të ndarë me presje.
  • NH_USE_BROADCAST. Vendosni vlerën në Disabled.
  • NH_TCPIP_METHOD. Metoda e parazgjedhur është UDP. Ju mund të ndryshoni në TCP, por në përgjithësi nuk ka nevojë serioze për këtë.

Një pikë tjetër në lidhje me shfaqjen e çelësave në monitorin aladdin. Në kundërshtim me besimin popullor, licencat falas nuk janë vetëm ato licenca që nuk përdoren në monitorin aladdin, por edhe ato që kanë 0 në fushën Timeout. Vlerat zakonisht zhduken brenda 36 orëve, por licencat ende konsiderohen të lira.

Në përfundim
Mendova për një kohë të gjatë nëse ka ndonjë pikë në një artikull të tillë, në fund të fundit, e gjithë kjo mund të gjendet në internet, megjithatë, duke pasur parasysh kohën që kalova vetë për të mbledhur të gjitha informacionet, mendova se do të ishte shumë mirë nëse të paktën dikush këtë Artikulli do të jetë i dobishëm dhe do të kursejë kohë.

Artikuj të ngjashëm: