FAQ

what does “max activations” field mean in terms of floating licenses? when you install floating licenses on the floating server, max activations field determines on how many servers you are able to install that same license on how do i control which device is allowed to connect to the floating server? floating server is designed to be deployed in a secure internal network (e g with vpn) therefore, each user should be a trusted user if you still want to authenticate users, you can setup an authentication proxy for floating server when configuring licenses for floating server, why do i need to enter both product and license key? floating server can be configured with multiple licenses at the same time setting the product allows us to determine to which product that license corresponds to i configured floating server with one license how do i add a different license for the same product? you are not able to add multiple licenses for the same product if you want to change the license, you can remove the old license and add the new one floating server requires api and shared keys is it safe to share them with my customers? those keys only give you access to the license api, and not to the management api license api is a very limited subset of licensespring api, so it is safe to share those keys can the on prem server run headless (command line only, no ui)? yes, the on prem server can be run headless after deployment using any of the available options, you can communicate with the server through command line scripts these scripts can be generated using our tool at licensespring api documentation every server functionality can be executed with corresponding command line arguments how does the on prem license server node lock to the system? when a license is activated through the on prem server, the server uses the machine identifier of the operating system to generate a unique hardware id, binding the license to that specific system in docker setups, the machine id is derived from the host machine’s id, and the license is tied to this hardware id for future operations is there a better implementation for node locking in docker setups on systems without internet access? yes, node locking in docker containers can be effectively implemented if the docker volumes remain secure and unmodified our recommendation is to secure the redis instance’s docker volume, as it plays a key role in the node locking mechanism for systems without internet access, we provide offline or air gapped licenses, which do not require internet connectivity alternatively, physical hardware keys (dongles) can be used to enforce node locking, requiring their presence for license validation can vm detection handle wsl detection from inside a wsl linux instance? no, currently, our floating server does not support detection of wsl (windows subsystem for linux) instances how is the hardware id determined by default? the hardware id is generated using the machine identifier from the underlying operating system or host machine this unique id is used to bind licenses to the system where the floating server is running how can i prevent server cloning when using the executable in air gapped or virtualized deployments? to protect against server cloning, the hardware id is used to tie the server to a specific machine licensespring also supports yubikey 5 hardware based security for additional protection if your environment doesn't allow external hardware (such as in fully virtualized systems), it's recommended to use expiration dates on licenses as an alternative safeguard licensespring is exploring software only server cloning prevention protocols that may be available in the future is the floating license server's database (badger db) running as a separate process in the executable method? no, the badger db database is integrated directly into the floating server executable (floating server exe) there is no separate process to manage the database runs within the executable, making it easier to monitor and control without extra overhead