License Manager for 1C in a virtual environment + monitoring in Zabbix

In many companies, 1C is used as the main automation platform. So it was with us. However, the process of establishing the platform was carried out without a proper approach, in connection with which we first had 5 protection keys for 95 licenses, then 3 more physical keys appeared to provide 50 more client licenses for 3 legal entities. The situation is stupid, since each key normally requires separate hosts, and the servers suitable for this were getting smaller, and the looming increase in the number of users and, consequently, the purchase of new keys made me think about an alternative solution to avoid unnecessary information load on our servers and generally make the system with keys more flexible and, preferably, more stable.

System selection

Virtualization system

As a visualization system was selected esxi 5.1. Selected for good support for the transfer of USB devices and because in addition to ESX, I only understand Hyper-V, which does not support the transfer of devices.

To transfer USB devices to ESX, the guest’s hardware should be at least version 7. Then it will be possible to add a USB controller and add a USB device to the guest system. There is still a moment about support. Officially, VMware only supports a specific list of devices. And it is not very big. However, ordinary security keys Aladdin, it seems, will be supported. The list of supported devices is on the official website here . And the description of the requirements and regulations on USB transfer to the guest system is also on the official website, in the knowledge base here .

There are also alternative ways of probing USB keys into a virtual environment, and also into a physical one. These are devices and software called USB over IP. Software products in this case are not very interesting to consider, but the iron ones in this case show themselves well. The brightest representative, the well-known AnywhereUSB with 14 ports. It is installed in a rack, it has two interfaces and two power inputs (does it really have two power supplies, I don't know :)). The device is good for everyone, but it costs an average of 60 thousand rubles, which did not fit into our budget.
')
So, after tests and tests, the virtualization platform was chosen and abandoned the use of other products.

Operating system and HASP drivers

I chose Debian as the OS. Why? Just because. In fact, in this configuration, you can take any favorite distribution. But I always like Debian with stability and a good repository.

The drivers are taken quite popular package from the company Etersoft . You can get the compiled package for your distribution kit on the company's FTP server: ftp.etersoft.ru/pub/Etersoft/HASP/stable .
After installing the package, the haspd service haspd , which controls the operation of the key.

Setup and Verification

All this does not require any additional configuration. The key starts working almost out of the box.
We are checking. To check the functionality in the kit has a program haspdemo . If the key is successfully identified and started, the program will output something similar to the console:

This is a simple demo program for the hasp4 key
Copyright © Aladdin Knowledge Systems Ltd.

LOCALHASP_ISHASP: Result: 1

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

LOCALHASP_ENCODEDATA: OK.
53 C1 F1 AF | EC 16 C3 15 | 35 31 E4 7F | 9B D0 90 9F [S ....... 51 ....]
AA BA 8C 80 | 1E 22 29 E2 | 92 7E 04 56 | DA 70 7B 63 [..... ") .. ~ .Vp {c]
23 B4 9B E6 | 2F 17 | | [# ... /.]

NETHASP_READBLOCK: Failed: Return status: 10

Main field: LOCALHASP_ISHASP : Result: 1 . Reporting that everything is fine. Further it is written and about what key is inserted.

However, if there is any problem, the message is shorter:

This is a simple demo program for the hasp4 key
Copyright © Aladdin Knowledge Systems Ltd.

LOCALHASP_ISHASP: Failed: status = -100

While in essence, it doesn’t matter what happens to the key, it may not be inserted, the service may not be running, or something else. I have only seen two LOCALHASP_ISHASP. : Result: 1 values LOCALHASP_ISHASP. : Result: 1 LOCALHASP_ISHASP. : Result: 1 , or : Failed: status = -100 . And the last always corresponded to the inoperability, and the first always meant that everything was OK. I did not find any documentation for this package, so I’d not find out what other statuses there are.

With the key figured out. We must not forget that in the key monitor your new key will appear only when at least one license is taken from it. Then aladdin monitor will show the information that it usually shows: this is the key type, the number of licenses taken, the total licenses, who exactly took the license and timeout.
To force it is quite simple, it is enough to indicate in the client's nethasp.ini with your hands a new license manager. But about setting up the client a little bit later.

From this point on, the initial task can be considered completed. Now we can create several virtual machines in parallel, in an amount corresponding to the number of available physical keys. Resources such virtualka consume, of course, penny.

Problems and Solutions

Single point of failure

The first problem that is created and in plain sight is the creation of a point of failure. If before that the keys were distributed across different servers and the failure of more than one key is practically excluded, in this case the failure of the physical server may result in the failure of the entire 1C system to work, because clients will fall off within, in my opinion, 600 seconds and after a short time, everyone will fall off and will not be able to return to the system. What follows such an incident can not tell. There are two possible solutions and are directed in a different direction. The first solution is to use the ESX failover configuration. However, it is advisable if in your company this system has already been deployed and a number of requirements have been fulfilled to maintain operability in case of failure of any component. Another solution is more trivial:
We create a group of A records in our company's DNS. For example, key1, key2, key3, and so on. We enter DNS names in nethasp.ini clients, distribute the file using group policy. Thus we get a fairly flexible access structure. In this case, after detecting a significant problem with the esx virtual server, you can quickly move the keys to any other servers, incl. at workstations of any staff. In parallel, we replace A records with new ones. For some time, the cash on clients will end and they will again be able to take a new license and continue working.
I recommend registering reverse DNS entries for keys, otherwise aladdin monitor will not show the host name, but will only show the license manager ID, which is not very convenient.
If the broadcast method of delivering keys is used in your company and in everything, then everything becomes easier even when moving a key to another host within the broadcast domain, it doesn’t affect your work.

Keys fall off

There is such a fairly common problem. The keys fall off. No special connection was noticed. This happens on different controllers, even on different host systems. When I transferred the keys and temporarily placed them in another place under the control of VMware Player, the keys were rolled off frequently. This is quite trivial. When you request haspdemo , the line LOCALHASP_ISHASP : Failed: status = -100 appears. Although the key is inserted and detected. dmseg shows not completely clear lines: usb 2-2.1: usbfs: USBDEVFS_CONTROL failed cmd aksusbd rqt 192 rq 139 len 8 ret -110
The problem is solved as trivially as it looks - restart the service. But the sediment remains and until this is done, the server will not distribute the keys. Since I want the system to work smoothly, it was decided to write a script that would restore the license manager itself. So, with the help of a friend, a script was written that runs haspdemo and tries to understand whether the status returns normally or not:
[ "`haspdemo | sed -n 's/^LOCALHASP_ISHASP.* \(\-\?[0-9]*\)$/\1/p'`" == "-100" ] && service haspd restart
Next, this script is inserted into the launch on CRON every minute and that's it. Even if the problem of falling ports is not observed in your system, I think this script will not hurt.

The problem of finding the key by the client

And there is such a problem. It lies in the fact that the client after losing the key may not want to take a new key. This problem can also be expressed in other manifestations. For example, if you replaced the paths to the keys in the nethasp.ini file, the client application can quite cheerfully continue to report that there are no keys and have never seen any. If you are not ready for such a reaction, the problem becomes very unpleasant and you start frantically checking the work of the whole system and shutting 1C-mat, because everything works, but now GlavBukh or, unfortunately, General, cannot enter into 1Sk now for an incomprehensible reason and you feel like an idiot, instead of quickly solving a problem. However, a rather simple solution has so far helped. It is necessary to clear the 1C cache from the user profile. At one time I found a separate file that is responsible for this information, but I forgot what :(

Keys can just stop working.

Against equipment failure no one is insured. And these pathetic keys can also stop working. And the most important thing in this case is to find out as soon as possible. For this we will use the monitoring system Zabbix. Of course, deploying it only for monitoring the keys is pointless, but if zabbiks is already there, then why not fasten monitoring of the status of the keys to it.
To do this, we need to register our own script in the agent settings file. We are looking for the configuration file of the installed zabbix_agent, it is called zabbix_agentd.conf. Open it and add the line

UserParameter=hasp.status,haspdemo | grep "^LOCALHASP_ISHASP" | sed 's/^.* \(\-\?[0-9]*\)$/\1/g'

This will allow the team to collect a digital value in the field LOCALHASP_ISHASP . In the zabbix itself, everything is added primitively; we create an Item for the desired host or template, specify the Zabbix agent as the Type , specify the hasp.status as the key parameter. The value type is float . If you wish, we create a trigger, according to which a letter or SMS will be sent to you that the key does not work. It is better to configure this trigger in such a way that it would require at least 2x operations and cover the time required for the autorecovery script described above, otherwise false reports about problems with the key will appear.
If the settings are correct, only if the key is completely inoperable, you will receive a notification of problems.

Bonus

It turned out to be a surprise for me, but many people really do not know that it is possible to force client parts of 1C to search for keys at the specified IP addresses using a TCP or UDP connection. Indeed, many people set up the infrastructure so that there are enough keys in each broadcast domain. This is wildness. For those who are not in the know here is a brief instruction:
To control access to the hasp key, the client has a nethasp.ini file. It is located in the folder \ conf directory 1C. We are interested in the [NH_TCPIP] section. In this section, we need to uncomment or create the following parameters:

• NH_SERVER_ADDR. Here we specify a list of DNS imet or IP addresses of servers with a license manager separated by commas.
• NH_USE_BROADCAST. Put the value in Disabled.
• NH_TCPIP_METHOD. By default, the UDP method is used. You can change to TCP, but in general this is not a serious need.

Another point about displaying keys in aladdin monitor. Contrary to popular belief, free licenses are not only those licenses that are absent as employed in aladdin monitor, but also those that have a value of 0 in the Timeout field. Values ​​usually disappear for 36 hours, but still licenses are considered free.

In conclusion

I thought for a long time whether there was any sense in a similar article, after all, all this can be found on the Internet, however, considering the time I spent to collect all the information, I thought it would be very good if at least someone The article will be useful and save time.