ingångÖvervakningslicenser 1c epf. En enda punkt av misslyckande
- Handledning
Många företag använder 1C som den huvudsakliga automationsplattformen. Så det hände med oss. Processen för att etablera plattformen genomfördes dock utan ett korrekt tillvägagångssätt, och därför hade vi först 5 skyddsnycklar för 95 licenser, sedan verkade ytterligare 3 fysiska nycklar ge ytterligare 50 klientlicenser för 3 juridiska personer. Situationen är dum, eftersom varje nyckel normalt kräver separata värdar, och det finns allt färre servrar som lämpar sig för detta, och den hotande ökningen av antalet användare och följaktligen köpet av nya nycklar fick mig att fundera på en alternativ lösning för att undvika onödig informationsbelastning på våra servrar och generellt göra nyckelsystemet mer flexibelt och helst mer stabilt.
Systemval
Virtualiseringssystem
Esxi 5.1 valdes som visualiseringssystem. Vald för bra stöd för överföring av USB-enheter och för att jag förutom ESX bara förstår Hyper-V, som inte stöder överföring av enheter. För att överföra USB-enheter till ESX måste gästsystemets hårdvara vara minst version 7. Då kommer det att vara möjligt att lägga till en USB-kontroller och ansluta USB-enheten till gästsystemet. Det finns också en stund om stöd. Officiellt stöder VMware endast en specifik lista över enheter. Och det är inte särskilt stort. Men Aladdins generiska säkerhetsnycklar verkar stödjas. Listan över enheter som stöds finns på den officiella webbplatsen. En beskrivning av kraven och bestämmelserna för USB-överföring till gästsystemet finns också på den officiella webbplatsen, i kunskapsbasen.
Det finns också alternativa sätt att vidarebefordra USB-nycklar till en virtuell miljö och även till en fysisk. Dessa enheter och mjukvara är så kallade USB over IP. I det här fallet är mjukvaruprodukter inte särskilt intressanta att överväga, men hårdvaruprodukter i det här fallet visar sig väl. Den ljusaste representanten, den välkända AnywhereUSB med 14 portar. Den är installerad i ett rack, har två gränssnitt och två strömingångar (har den verkligen två nätaggregat, jag vet inte :)). Enheten är bra för alla, men den kostar i genomsnitt 60 tusen rubel, vilket inte passade väl in i vår budget.
Så, efter tester och tester, valdes virtualiseringsplattformen och vägrade att använda andra produkter.
Operativsystem och HASP-drivrutiner
Jag valde Debian som operativsystem. Varför? Bara för att. Faktum är att i den här konfigurationen kan du ta vilken favoritdistributionssats som helst. Men jag gillar alltid Debian för dess stabilitet och ett bra arkiv.
Ett ganska populärt paket från Etersoft tas som drivrutiner. Du kan få det kompilerade paketet för ditt distributionspaket på företagets FTP-server: ftp.etersoft.ru/pub/Etersoft/HASP/stable.
Efter installation av paketet dyker haspd-tjänsten upp, som hanterar nyckelns funktion.
Ställ in och kontrollera
Allt detta kräver ingen ytterligare konfiguration. Nyckeln börjar fungera nästan ur kartongen.Kontroll. För att kontrollera funktionaliteten ingår haspdemo-programmet i satsen. Efter framgångsrik identifiering av nyckeln och påbörjad arbete kommer programmet att visa något som liknar konsolen:
LOCALHASP_ISHASP: Resultat: 1
Använda lösenord 15213 - 28875
LOCALHASP_HASPSTATUS: API-versionsnummer är 8.0
portnummer 201
Nyckeltyp: HASP4 M4
LOCALHASP_HASPGENERATION: OK, HASP4 är ansluten.
LOCALHASP_HASPNETSTATUS: ansluten nyckel är HASP4 Net 20
MEMOHASP_HASPID: 436444258 (decimal), 0x1a039c62 (hex)LOCALHASP_ENCODEDATA: OK.
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: Misslyckades: Returstatus: 10
Huvudfält: LOCALHASP_ISHASP: Resultat: 1. Meddelar att allt är i sin ordning. Vidare skrivs det om vilken nyckel som är insatt.
Men om det finns något problem visas meddelandet kortare:
Detta är ett enkelt demoprogram för HASP4-nyckeln
Copyright Aladdin Knowledge Systems Ltd.LOCALHASP_ISHASP: Misslyckades: status = -100
Dessutom spelar det faktiskt ingen roll vad som händer med nyckeln, den kanske inte sätts in, tjänsten kanske inte startas eller något annat. Jag har bara sett två LOCALHASP_ISHASP-värden hittills. Detta är antingen: Resultat: 1 eller: Misslyckades: status = -100. Och det sistnämnda motsvarade alltid inoperabilitet, och det första betydde alltid att allt var OK. Jag hittade inte dokumentationen för detta paket, så det gick inte att ta reda på vilka andra statusar som finns.
Med nyckeln i ordning. Vi får inte glömma att din nytillverkade nyckel visas i nyckelmonitorn först när minst en licens har tagits från den. Sedan kommer aladdin monitor att visa informationen som den vanligtvis visar: detta är typen av nyckel, antalet tagna licenser, totalt antal licenser, vem som tog licensen och timeout.
Det är ganska enkelt att tvinga fram det, det räcker att specificera den nya licenshanteraren i klienten nethasp.ini för hand. Men om att sätta upp klienten lite senare.
Från och med denna tidpunkt kan den ursprungliga uppgiften anses vara avslutad. Nu kan vi skapa flera virtuella maskiner parallellt, i en mängd som motsvarar antalet tillgängliga fysiska nycklar. Resurser sådana virtuella maskiner förbrukar, naturligtvis, en slant.
Problem och lösningar
En enda punkt av misslyckande
Det första problemet som skapas och som är synligt är skapandet av en punkt av misslyckande. Om nycklarna innan dess distribuerades över olika servrar och fel på mer än en nyckel praktiskt taget är uteslutet, kan i det här fallet felet på den fysiska servern resultera i fel på hela 1C-systemet, eftersom klienter kommer att falla av inom, enligt min mening, 600 sekunder och efter en kort tid kommer allt att falla av och kommer inte att kunna återgå till systemet. Vad som kommer att följa efter en sådan incident kan du inte säga. Det finns två lösningar och är riktade åt olika håll. Den första lösningen är att använda en feltolerant ESX-konfiguration. Detta är dock tillrådligt om ditt företag redan har implementerat detta system och redan har uppfyllt ett antal krav för att upprätthålla driftbarheten i händelse av fel på någon komponent. En annan lösning är mer trivial:Vi skapar grupp A-poster i vårt företags DNS. Till exempel nyckel1, nyckel2, nyckel3 och så vidare. Vi anger DNS-namn i klienternas nethasp.ini, distribuerar filen med hjälp av gruppolicy. Därmed får vi en ganska flexibel åtkomststruktur. I det här fallet, efter att ha upptäckt ett betydande problem med den virtuella esx-servern, kan du snabbt flytta nycklarna till andra servrar, inkl. till eventuella anställdas arbetsstationer. Parallellt byter vi ut A-skivor med nya. Under en tid kommer cachen på klienterna att ta slut och de kommer återigen att kunna ta en ny licens och fortsätta arbeta.
Jag rekommenderar att du registrerar omvända DNS-poster för nycklarna, annars visar aladdin monitor inte värdnamnet, utan visar bara ID för licenshanteraren, vilket inte är särskilt bekvämt.
Om ditt företag och alla använder sändningsmetoden för nyckelleverans, så är allt förenklat och att flytta nyckeln till en annan värd inom sändningsdomänen kommer inte att påverka arbetet på något sätt.
Nycklar ramlar av
Det finns ett ganska vanligt problem. Nycklarna faller av. Något speciellt samband märktes dock inte. Detta händer på olika kontroller, även på olika värdsystem. När jag överförde nycklarna och tillfälligt placerade dem på en annan plats under kontroll av VMware Player, inträffade återställning av nycklar ofta. Detta uttrycks ganska trivialt. När du begär haspdemo, visas raden LOCALHASP_ISHASP: Misslyckades: status = -100. Även om nyckeln är insatt och upptäckbar. dmseg visar ofullständigt förstådda rader: usb 2-2.1: usbfs: USBDEVFS_CONTROL misslyckades cmd aksusbd rqt 192 rq 139 len 8 ret -110Problemet löses lika trivialt som det ser ut - genom att starta om tjänsten. Men sedimentet finns kvar och tills detta är gjort kommer inte servern att distribuera nycklarna. Eftersom jag ville att systemet skulle fungera felfritt beslutades det att skriva ett skript som skulle återställa driften av själva licenshanteraren. Så med hjälp av en vän skrevs ett manus som startar haspdemo och försöker ta reda på om statusen återgår till normal eller inte:
["` haspdemo | sed -n "s / ^ LOCALHASP_ISHASP. * \ (\ - \? * \) $ / \ 1 / p" `" == "-100"] && tjänsten haspd omstart
Sedan infogas det här skriptet i CRON-starten varje minut och det är allt. Även om ditt system inte har problemet med att tappa portar, tror jag inte det här skriptet kommer att skada.
Upptäckt problem med klientnyckel
Och det finns ett sådant problem. Den består i att klienten, efter att ha tappat bort nyckeln, kanske inte vill ta en ny nyckel. Detta problem kan också uttryckas i andra manifestationer. Om du till exempel ändrade sökvägarna till nycklarna i nethasp.ini-filen, kan klientapplikationen ganska glatt fortsätta att rapportera att det inte finns några nycklar och aldrig har sett dem. Om du inte är redo för en sådan reaktion, blir problemet väldigt obehagligt och du börjar frenetiskt kontrollera driften av hela systemet och förbanna 1C-smeknamn, eftersom allt fungerar, men GlavBukh eller, som tur är, generalen, kan av okänd anledning inte komma in på 1Sku nu och du känner dig som en idiot istället för att snabbt lösa problemet. En ganska enkel lösning har dock hjälpt hittills. Det är nödvändigt att rensa 1C-cachen från användarprofilen. Vid ett tillfälle hittade jag en separat fil som är ansvarig för denna information, jag har glömt vilken :(Nycklar kanske bara slutar fungera
Ingen är försäkrad mot utrustningsfel. Och de där ynka nycklarna kan också sluta fungera. Och det viktigaste i det här fallet är att ta reda på det så tidigt som möjligt. För detta kommer vi att använda Zabbix övervakningssystem. Naturligtvis är det meningslöst att distribuera den bara för att övervaka nycklarna, men om Zabbix redan är installerad, varför inte skruva övervakning av nycklarnas tillstånd till den.För att göra detta måste vi skriva vårt eget skript i agentinställningsfilen. Vi letar efter konfigurationsfilen för den installerade zabbix_agenten, den heter zabbix_agentd.conf. Öppna den och lägg till raden
UserParameter = hasp.status, haspdemo | grep "^ LOCALHASP_ISHASP" | sed "s /^.* \ (\ - \? * \) $ / \ 1 / g"
Detta gör att kommandot samlar in det digitala värdet i fältet LOCALHASP_ISHASP. I själva Zabbix läggs allt till redan primitivt, vi skapar Artikel för önskad värd eller mall, som Typ ange Zabbix agent, som nyckelparameter, specificera hasp.status... Värde typ - flyta... Om så önskas, skapa en trigger som du kommer att skickas ett brev eller SMS om att nyckeln inte fungerar. Det är bättre att konfigurera den här utlösaren på ett sådant sätt att den skulle kräva minst 2 operationer och täcka den tid som krävs för det automatiska återställningsskriptet som beskrivs ovan, annars visas falska meddelanden om problem med nyckeln.
Om inställningarna är korrekta, endast om nyckeln är helt inoperabel, kommer du att få ett meddelande om problem.
Bonus
Det visade sig vara en överraskning för mig, men många vet verkligen inte att det är möjligt att tvinga klientdelarna i 1C att söka efter nycklar på de angivna IP-adresserna med hjälp av en TCP- eller UDP-anslutning. Faktum är att många människor konfigurerar infrastrukturen så att det finns tillräckligt med nycklar i varje sändningsdomän. Det här är vildhet. För de som ännu inte är insatta, här är en snabbguide:För att kontrollera åtkomsten till hasp-nyckeln har klienten en nethasp.ini-fil. Den finns i mappen \ conf i 1C-katalogen. Vi är intresserade av avsnittet. I det här avsnittet måste vi avkommentera eller skapa följande parametrar:
- NH_SERVER_ADDR. Här anger vi en lista över DNS- eller IP-adresser för servrar med en licenshanterare separerade med kommatecken.
- NH_USE_BROADCAST. Ställ in värdet på Disabled.
- NH_TCPIP_METHOD. Som standard används UDP-metoden. Kan ändras till TCP, men i allmänhet inte nödvändigt.
En annan punkt om visningen av nycklar i aladdin-monitorn. I motsats till vad många tror är gratislicenser inte bara de som inte är tillgängliga i aladdin-monitorn, utan även de med 0 i Timeout-fältet. Värden försvinner vanligtvis inom 36 timmar, men licenser anses fortfarande vara gratis.
Sammanfattningsvis
Jag funderade länge på om det var någon mening med en sådan artikel, trots allt kan allt detta hittas på Internet, men efter att ha räknat tiden som jag själv spenderade för att samla in all information, trodde jag att det skulle vara mycket bra om åtminstone någon hade detta artikeln kommer att vara användbar och spara tid.- Handledning
Många företag använder 1C som den huvudsakliga automationsplattformen. Så det hände med oss. Processen för att etablera plattformen genomfördes dock utan ett korrekt tillvägagångssätt, och därför hade vi först 5 skyddsnycklar för 95 licenser, sedan verkade ytterligare 3 fysiska nycklar ge ytterligare 50 klientlicenser för 3 juridiska personer. Situationen är dum, eftersom varje nyckel normalt kräver separata värdar, och det finns allt färre servrar som lämpar sig för detta, och den hotande ökningen av antalet användare och följaktligen köpet av nya nycklar fick mig att fundera på en alternativ lösning för att undvika onödig informationsbelastning på våra servrar och generellt göra nyckelsystemet mer flexibelt och helst mer stabilt.
Systemval
Virtualiseringssystem
Esxi 5.1 valdes som visualiseringssystem. Vald för bra stöd för överföring av USB-enheter och för att jag förutom ESX bara förstår Hyper-V, som inte stöder överföring av enheter. För att överföra USB-enheter till ESX måste gästsystemets hårdvara vara minst version 7. Då kommer det att vara möjligt att lägga till en USB-kontroller och ansluta USB-enheten till gästsystemet. Det finns också en stund om stöd. Officiellt stöder VMware endast en specifik lista över enheter. Och det är inte särskilt stort. Men Aladdins generiska säkerhetsnycklar verkar stödjas. Listan över enheter som stöds finns på den officiella webbplatsen. En beskrivning av kraven och bestämmelserna för USB-överföring till gästsystemet finns också på den officiella webbplatsen, i kunskapsbasen.
Det finns också alternativa sätt att vidarebefordra USB-nycklar till en virtuell miljö och även till en fysisk. Dessa enheter och mjukvara är så kallade USB over IP. I det här fallet är mjukvaruprodukter inte särskilt intressanta att överväga, men hårdvaruprodukter i det här fallet visar sig väl. Den ljusaste representanten, den välkända AnywhereUSB med 14 portar. Den är installerad i ett rack, har två gränssnitt och två strömingångar (har den verkligen två nätaggregat, jag vet inte :)). Enheten är bra för alla, men den kostar i genomsnitt 60 tusen rubel, vilket inte passade väl in i vår budget.
Så, efter tester och tester, valdes virtualiseringsplattformen och vägrade att använda andra produkter.
Operativsystem och HASP-drivrutiner
Jag valde Debian som operativsystem. Varför? Bara för att. Faktum är att i den här konfigurationen kan du ta vilken favoritdistributionssats som helst. Men jag gillar alltid Debian för dess stabilitet och ett bra arkiv.
Ett ganska populärt paket från Etersoft tas som drivrutiner. Du kan få det kompilerade paketet för ditt distributionspaket på företagets FTP-server: ftp.etersoft.ru/pub/Etersoft/HASP/stable.
Efter installation av paketet dyker haspd-tjänsten upp, som hanterar nyckelns funktion.
Ställ in och kontrollera
Allt detta kräver ingen ytterligare konfiguration. Nyckeln börjar fungera nästan ur kartongen.Kontroll. För att kontrollera funktionaliteten ingår haspdemo-programmet i satsen. Efter framgångsrik identifiering av nyckeln och påbörjad arbete kommer programmet att visa något som liknar konsolen:
LOCALHASP_ISHASP: Resultat: 1
Använda lösenord 15213 - 28875
LOCALHASP_HASPSTATUS: API-versionsnummer är 8.0
portnummer 201
Nyckeltyp: HASP4 M4
LOCALHASP_HASPGENERATION: OK, HASP4 är ansluten.
LOCALHASP_HASPNETSTATUS: ansluten nyckel är HASP4 Net 20
MEMOHASP_HASPID: 436444258 (decimal), 0x1a039c62 (hex)LOCALHASP_ENCODEDATA: OK.
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: Misslyckades: Returstatus: 10
Huvudfält: LOCALHASP_ISHASP: Resultat: 1. Meddelar att allt är i sin ordning. Vidare skrivs det om vilken nyckel som är insatt.
Men om det finns något problem visas meddelandet kortare:
Detta är ett enkelt demoprogram för HASP4-nyckeln
Copyright Aladdin Knowledge Systems Ltd.LOCALHASP_ISHASP: Misslyckades: status = -100
Dessutom spelar det faktiskt ingen roll vad som händer med nyckeln, den kanske inte sätts in, tjänsten kanske inte startas eller något annat. Jag har bara sett två LOCALHASP_ISHASP-värden hittills. Detta är antingen: Resultat: 1 eller: Misslyckades: status = -100. Och det sistnämnda motsvarade alltid inoperabilitet, och det första betydde alltid att allt var OK. Jag hittade inte dokumentationen för detta paket, så det gick inte att ta reda på vilka andra statusar som finns.
Med nyckeln i ordning. Vi får inte glömma att din nytillverkade nyckel visas i nyckelmonitorn först när minst en licens har tagits från den. Sedan kommer aladdin monitor att visa informationen som den vanligtvis visar: detta är typen av nyckel, antalet tagna licenser, totalt antal licenser, vem som tog licensen och timeout.
Det är ganska enkelt att tvinga fram det, det räcker att specificera den nya licenshanteraren i klienten nethasp.ini för hand. Men om att sätta upp klienten lite senare.
Från och med denna tidpunkt kan den ursprungliga uppgiften anses vara avslutad. Nu kan vi skapa flera virtuella maskiner parallellt, i en mängd som motsvarar antalet tillgängliga fysiska nycklar. Resurser sådana virtuella maskiner förbrukar, naturligtvis, en slant.
Problem och lösningar
En enda punkt av misslyckande
Det första problemet som skapas och som är synligt är skapandet av en punkt av misslyckande. Om nycklarna innan dess distribuerades över olika servrar och fel på mer än en nyckel praktiskt taget är uteslutet, kan i det här fallet felet på den fysiska servern resultera i fel på hela 1C-systemet, eftersom klienter kommer att falla av inom, enligt min mening, 600 sekunder och efter en kort tid kommer allt att falla av och kommer inte att kunna återgå till systemet. Vad som kommer att följa efter en sådan incident kan du inte säga. Det finns två lösningar och är riktade åt olika håll. Den första lösningen är att använda en feltolerant ESX-konfiguration. Detta är dock tillrådligt om ditt företag redan har implementerat detta system och redan har uppfyllt ett antal krav för att upprätthålla driftbarheten i händelse av fel på någon komponent. En annan lösning är mer trivial:Vi skapar grupp A-poster i vårt företags DNS. Till exempel nyckel1, nyckel2, nyckel3 och så vidare. Vi anger DNS-namn i klienternas nethasp.ini, distribuerar filen med hjälp av gruppolicy. Därmed får vi en ganska flexibel åtkomststruktur. I det här fallet, efter att ha upptäckt ett betydande problem med den virtuella esx-servern, kan du snabbt flytta nycklarna till andra servrar, inkl. till eventuella anställdas arbetsstationer. Parallellt byter vi ut A-skivor med nya. Under en tid kommer cachen på klienterna att ta slut och de kommer återigen att kunna ta en ny licens och fortsätta arbeta.
Jag rekommenderar att du registrerar omvända DNS-poster för nycklarna, annars visar aladdin monitor inte värdnamnet, utan visar bara ID för licenshanteraren, vilket inte är särskilt bekvämt.
Om ditt företag och alla använder sändningsmetoden för nyckelleverans, så är allt förenklat och att flytta nyckeln till en annan värd inom sändningsdomänen kommer inte att påverka arbetet på något sätt.
Nycklar ramlar av
Det finns ett ganska vanligt problem. Nycklarna faller av. Något speciellt samband märktes dock inte. Detta händer på olika kontroller, även på olika värdsystem. När jag överförde nycklarna och tillfälligt placerade dem på en annan plats under kontroll av VMware Player, inträffade återställning av nycklar ofta. Detta uttrycks ganska trivialt. När du begär haspdemo, visas raden LOCALHASP_ISHASP: Misslyckades: status = -100. Även om nyckeln är insatt och upptäckbar. dmseg visar ofullständigt förstådda rader: usb 2-2.1: usbfs: USBDEVFS_CONTROL misslyckades cmd aksusbd rqt 192 rq 139 len 8 ret -110Problemet löses lika trivialt som det ser ut - genom att starta om tjänsten. Men sedimentet finns kvar och tills detta är gjort kommer inte servern att distribuera nycklarna. Eftersom jag ville att systemet skulle fungera felfritt beslutades det att skriva ett skript som skulle återställa driften av själva licenshanteraren. Så med hjälp av en vän skrevs ett manus som startar haspdemo och försöker ta reda på om statusen återgår till normal eller inte:
["` haspdemo | sed -n "s / ^ LOCALHASP_ISHASP. * \ (\ - \? * \) $ / \ 1 / p" `" == "-100"] && tjänsten haspd omstart
Sedan infogas det här skriptet i CRON-starten varje minut och det är allt. Även om ditt system inte har problemet med att tappa portar, tror jag inte det här skriptet kommer att skada.
Upptäckt problem med klientnyckel
Och det finns ett sådant problem. Den består i att klienten, efter att ha tappat bort nyckeln, kanske inte vill ta en ny nyckel. Detta problem kan också uttryckas i andra manifestationer. Om du till exempel ändrade sökvägarna till nycklarna i nethasp.ini-filen, kan klientapplikationen ganska glatt fortsätta att rapportera att det inte finns några nycklar och aldrig har sett dem. Om du inte är redo för en sådan reaktion, blir problemet väldigt obehagligt och du börjar frenetiskt kontrollera driften av hela systemet och förbanna 1C-smeknamn, eftersom allt fungerar, men GlavBukh eller, som tur är, generalen, kan av okänd anledning inte komma in på 1Sku nu och du känner dig som en idiot istället för att snabbt lösa problemet. En ganska enkel lösning har dock hjälpt hittills. Det är nödvändigt att rensa 1C-cachen från användarprofilen. Vid ett tillfälle hittade jag en separat fil som är ansvarig för denna information, jag har glömt vilken :(Nycklar kanske bara slutar fungera
Ingen är försäkrad mot utrustningsfel. Och de där ynka nycklarna kan också sluta fungera. Och det viktigaste i det här fallet är att ta reda på det så tidigt som möjligt. För detta kommer vi att använda Zabbix övervakningssystem. Naturligtvis är det meningslöst att distribuera den bara för att övervaka nycklarna, men om Zabbix redan är installerad, varför inte skruva övervakning av nycklarnas tillstånd till den.För att göra detta måste vi skriva vårt eget skript i agentinställningsfilen. Vi letar efter konfigurationsfilen för den installerade zabbix_agenten, den heter zabbix_agentd.conf. Öppna den och lägg till raden
UserParameter = hasp.status, haspdemo | grep "^ LOCALHASP_ISHASP" | sed "s /^.* \ (\ - \? * \) $ / \ 1 / g"
Detta gör att kommandot samlar in det digitala värdet i fältet LOCALHASP_ISHASP. I själva Zabbix läggs allt till redan primitivt, vi skapar Artikel för önskad värd eller mall, som Typ ange Zabbix agent, som nyckelparameter, specificera hasp.status... Värde typ - flyta... Om så önskas, skapa en trigger som du kommer att skickas ett brev eller SMS om att nyckeln inte fungerar. Det är bättre att konfigurera den här utlösaren på ett sådant sätt att den skulle kräva minst 2 operationer och täcka den tid som krävs för det automatiska återställningsskriptet som beskrivs ovan, annars visas falska meddelanden om problem med nyckeln.
Om inställningarna är korrekta, endast om nyckeln är helt inoperabel, kommer du att få ett meddelande om problem.
Bonus
Det visade sig vara en överraskning för mig, men många vet verkligen inte att det är möjligt att tvinga klientdelarna i 1C att söka efter nycklar på de angivna IP-adresserna med hjälp av en TCP- eller UDP-anslutning. Faktum är att många människor konfigurerar infrastrukturen så att det finns tillräckligt med nycklar i varje sändningsdomän. Det här är vildhet. För de som ännu inte är insatta, här är en snabbguide:För att kontrollera åtkomsten till hasp-nyckeln har klienten en nethasp.ini-fil. Den finns i mappen \ conf i 1C-katalogen. Vi är intresserade av avsnittet. I det här avsnittet måste vi avkommentera eller skapa följande parametrar:
- NH_SERVER_ADDR. Här anger vi en lista över DNS- eller IP-adresser för servrar med en licenshanterare separerade med kommatecken.
- NH_USE_BROADCAST. Ställ in värdet på Disabled.
- NH_TCPIP_METHOD. Som standard används UDP-metoden. Kan ändras till TCP, men i allmänhet inte nödvändigt.
En annan punkt om visningen av nycklar i aladdin-monitorn. I motsats till vad många tror är gratislicenser inte bara de som inte är tillgängliga i aladdin-monitorn, utan även de med 0 i Timeout-fältet. Värden försvinner vanligtvis inom 36 timmar, men licenser anses fortfarande vara gratis.
Sammanfattningsvis
Jag funderade länge på om det var någon mening med en sådan artikel, trots allt kan allt detta hittas på Internet, men efter att ha räknat tiden som jag själv spenderade för att samla in all information, trodde jag att det skulle vara mycket bra om åtminstone någon hade detta artikeln kommer att vara användbar och spara tid.
F: Övervakning av mjukvarulicenser
Svar:
Fråga: Problem med mjukvarulicenser på server 1c
Svar:
Fråga: Programvarulicens och COM-anslutning
En mjukvarulicens är installerad.
När man försöker starta 1C via Com-connection, skriver den:
-----------
Ingen gratis licens hittades!
Sök efter licenser på klienten:
Programvarulicensfel
Det maximala antalet användare som tillåts av mjukvarulicensfilen har överskridits.
Källa: V82.COMConnector.1
-----------
Vad är problemet?
Svar: Det maximala antalet användare som tillåts av mjukvarulicensfilen har överskridits.
F: Hur kan jag ta reda på vilken fil (.lic) som kvalificerar sig för vilken mjukvarulicens?
Svar:
Fråga: Knep för att utfärda programvarulicenser av 1C-servern
Svar:
F: CAL:er distribueras inte
Svar:
Fråga: Problem med att överföra 1C 8.3 mjukvarulicens till en ny server
God eftermiddag.
Företaget hade en fysisk 1C 8.3-server med redovisningsfilbaser. Den hade mjukvarulicenser på den.
Köpta licenser för 1c ERP:
1.till plattform för 20 personer
2.på konfiguration 3.på server 1 s Vi köpte också en ny rackserver, installerade 1C 8.3-plattformen på den, distribuerade en ERP-testbas, installerade mjukvarulicenser - allt är ok.
Det uppstod ett problem med överföringen av fildatabaser, eller snarare kopierade jag själva databaserna, men vid uppstart erbjuder 1C inte att ange en licens, men säger att licensen inte hittades och föreslår att man använder en hårdvaruskyddsnyckel.
Berätta för mig hur man kan erbjuda 1C att införa en mjukvarulicens för fildatabaser med bokföring på en ny server?
Svar: Super tack!
Fråga: v7: 1C 7.7 TiS - kan det finnas en mjukvarulicens?
Mötte TIS 7.7 lokalt utan hårdvarudongel. Såvitt jag minns, hade TiS 7.7 inga tillbehör med mjukvarulicens? Jag minns på 7-ke att det fanns några produkter med aktivering enligt ord från boken - man var tvungen att hitta ett ord på en sådan och en sida och sedan skedde aktivering, det vill säga utan skyddsnyckel. Men det verkar som att det här var någon slags branschlösningar, vad jag minns. Det finns en låda med frågeformulär, disketter och böcker, men nyckeln finns ingenstans. Det är sant att det inte finns någon LPT-port på datorn, kanske är det därför den inte installerades på en gång och försvann någonstans. Men ändå skulle jag vilja försäkra mig om att det inte fanns någon TIS med mjukvaruaktivering, bara med hårdvara? Plötsligt har jag bara alltid stött på hårdvara tidigare.
Svar:
Svar: