One of the big differences between being a good hobbyist with Linux and working commercially with it is dealing with proprietary software. You can use and configure all sorts of systems indefinitely on your own account and never come up against dealing with awkward proprietary software that is supposedly officially supported for your platform that you really need to make work. Recently I had this experience. Not only was I able to get it working but I was able to extend it beyond the manufacturer’s original provision to make it more user friendly and less work to administer.
I won’t name the software in question but it is an established market leading proprietary package in video effects post-production. My organisation had purchased a single floating license, principally for one artist to work with but we had another who also wished to use it. The manufacturer did not detail any process for setting up a license server and the software has online capability to check licenses so I presumed that they would simply look at our external IP and the number of copies already in use. Not so, as became apparent after using the software on a second machine.
After some dialogue with the Manufacturer it became apparent that their application (made available as tar.gz) included a license server in the $/bin directory which is used by default when the application is called. So to set up a license server, all I should need to do is install a copy of the application on the server host right? Except that they expect the license server to be called manually, yes really. In my case I had set up a minimal VM installation just to run the license server application and had no interest in shelling in periodically to manually start an application. Of course it would be too simple to have only this to deal with. It turns out that the application expects pre-systemd network device naming and otherwise has to be called with an environment variable specifying the connected network device name set for it to work correctly. What to do?
Well firstly I asked the manufacturer to supply me with a wrapper script to call the license server binary correctly. Yes I could probably have taken the time to do this myself but I am a paying customer and this is their proprietary application. Having received the wrapper I adapted to it to my specific installation location and network device name and put it on my server (I chose /opt because I prefer to install proprietary software there unless they request/document/presume /usr/local or something instead) as an executable shell script. Now for the cool part, setting it to run automatically at boot. For this we want a sytemd unit. Yes, I know that systemd is contentious but for better or for worse it is here and essentially all current ‘enterprise’ Linux distributions are using it. How is this done?:
Presuming original installation:
tar xvzf proprietary.tar.gz --directory /opt
And wrapper script
#!/bin/sh export LC_SYSTEMID_DEVICENAME=ens160 /opt/proprietary/bin/lc
We then set systemd to call the wrapper script at system startup:
[Unit] Description=proprietary license server [Service] ExecStart=/opt/proprietary_lc.run [Install] WantedBy=multi-user.target
We can now treat this as any other systemd unit:
systemctl enable proprietarylicenseserver.service systemctl start proprietarylicenseserver.service
Ta dah! The license server is now called as part of normal system start up without user interaction. It will be recorded in the journal as with other system services. You still need to ‘deal with’ any selinux and firewall issues in the normal way but you can be sure if your host is up then the license server has been called.
A couple of notes:
The above set up calls the license server as root. Yes I could have set it to run as a user level process but in this case the installation is a single-purpose VM with no user accounts so I’m not really bothered.
Properly the above systemd unit should include the line
immediately under [Service] but this is the default if nothing is specified, so, yeah… Do check which ‘Type’ matches your requirement however.
The wrapper script is called as part of the multi-user target. This ensures that there will be network connectivity available before the application is called and most closely mimics a manual start by a user.