To setup the ViewStation License Manager, follow these steps:
To setup the ViewStation License Manager, follow these steps:
sudo bash linux_deamon_install.sh
sudo bash linux_deamon_restart.sh
sudo bash linux_deamon_update.sh
The behavior of the ViewStation License Manager can be configured using a JSON file. In addition to general server settings, usage privileges and access permissions to features can also be regulated. To change the configuration, simply edit the ServerConfig.json file using a text editor as described below. Restart the VS License Manager for the changes to take effect.
The communication between the VS License Manager and the 3DViewStation clients uses the TCP network protocol. The TCP_PORT setting defines the port used:
"TCP_PORT": 6200,
The License Monitor, the web interface of the VS License Manager, can be accessed via an internet browser: <LicenseServerAddress>:<HTTP_PORT>. The HTTP port used is defined by the setting HTTP_PORT:
"HTTP_PORT": 6280,
"HTTP_PORT": 0
To access the Admin view in the License Monitor (including logs, configuration overview and checkout history), a password must be configured:
"ADMIN_PASSWORD": "SuperUser123",
Optionally, it is possible to configure a main password. With this setting enabled, even the basic License Monitor will prompt for a password before displaying any information.
"MAIN_PASSWORD": "",
The location of the VS License Manager log files can be changed using the LOG_PATH parameter. The path can be absolute or relative with a leading "./":
"LOG_PATH": "./Logs",
The log format can be specified with the eponymous parameter.
"LOG_FORMAT": "NORMAL",
The alternative log format to NORMAL is RESTRICTED, which suppresses the writing of usernames, hostnames and IP addresses in the log file and displaying them in the License Monitor. For support cases, it is possible to convert the recent log files from normal to restricted format using a button in the License Monitor.
It is possible to configure the number of days before old log files are removed.
"LOG_ARCHIVE_COUNT": 90,
The default is 90 files, which is equivalent to 90 days or 3 months. If you never want log files to be removed, set the value to zero.
It is possible to configure usage privileges in the VS License Manager by editing and saving the ServerConfig.json file. This includes allowing, denying, limiting and reserving the checkout and borrowing of features for specific users. Restart the VS License Manager for the changes to take effect.
When to use which privilege rule?
If you want most of your users to be able to use all features and only a few to be restricted, use Deny Rules.
If you want to allow a few privileged users to use certain features and restrict most of your users, use Allow Rules.
If you want to control the number of features available to different user groups, use Limit Rules and Reserve Rules.
How to specify users?
In each rule, users can be specified as usernames, hostnames or IP addresses (IPv4 or IPv6, see setting IP_VERSION) and must be seperated by a semicolon:
"USERS": "UserOne;UserTwo;UserThree;..."
If the list becomes large, or if the same list is used in multiple privilege rules, it is useful to define GROUPS at the end of the configuration file. The format for the MEMBERS is the same as for USERS. Curly braces {...} define a group within the group list [...], seperated by commas.
"GROUPS": [
{
"NAME": "Group 1",
"MEMBERS": "UserOne;UserTwo;UserThree;...;UserN"
},
{
"NAME": "Group 2",
"MEMBERS": "Host01;Host02;Host03;...;HostX"
}
]
You can now specify users as follows:
"USERS": "Group 1;Group 2"
Linking a group within another group is supported.
&
: "USERS" : "&My Users"
. Usage examples can be found below.
The ALLOW_CHECKOUTS and ALLOW_BORROWS rules restrict the use of features to all but the specified users. So if you have privileged users, use these settings. They consist of the following keywords:
*
if not used. Then the rule will apply for all features / serial numbers loaded by the VS License Manager.
Examples
A rule that allows functionality features only for selected users would look like this:
"ALLOW_CHECKOUTS": [
{
"FEATURES": "FUNCTIONALITY_ADVANCED_ANALYSIS;FUNCTIONALITY_TECHDOC",
"USERS": "Some user; Some other user; Another user"
}
],
To allow the general usage of the floating license only for selected users, set FEATURES to *
or remove the value completely:
"ALLOW_CHECKOUTS": [
{
"FEATURES": "*",
"USERS": "Some user; Some other user; Another user"
}
],
Allowing borrowing of EXPORT_ALL only for the MEMBERS defined in a GROUP with the NAME "Borrow Users" would look like this:
"ALLOW_BORROWS": [
{
"FEATURES": "EXPORT_ALL",
"USERS": "Borrow Users"
}
],
...
"GROUPS" : [
{
"NAME": "Borrow Users",
"MEMBERS": "Some user; Some other user; Another user"
}
]
The same rule, but restricting borrowing of all features for all users except the members of the defined group:
"ALLOW_BORROWS": [
{
"FEATURES": "*",
"USERS": "Borrow Users"
}
],
Multiple allow rules are seperated by commas:
"ALLOW_CHECKOUTS": [
{
"FEATURES": "FUNCTIONALITY_ADVANCED_ANALYSIS;FUNCTIONALITY_TECHDOC",
"USERS": "Functionality Users"
},
{
"FEATURES": "KAS",
"USERS": "KAS Users"
}
],
Allowing a feature only for a specific windows user group using the prefix &
would look like this:
"ALLOW_CHECKOUTS": [
{
"FEATURES": "EXPORT_ALL",
"USERS": "&WindowsGroup"
}
],
Allowing a feature for a specific hostname pattern would look like the following. This would allow all PC's with names like PC001 and PC456 or WS12CAD and WS34CAD.
"ALLOW_CHECKOUTS": [
{
"FEATURES": "EXPORT_ALL",
"USERS": "PC*;WS*CAD"
}
],
Allowing one of multiple licenses only for a specific IP domain would look like this:
"ALLOW_CHECKOUTS": [
{
"SERIALNUMBERS": "2024-0101-123456",
"USERS": "4.3.2.*"
}
],
Allowing a license only for a specific IP range would look like this:
"ALLOW_CHECKOUTS": [
{
"COMMENT": "A specific IP range",
"USERS": "4.3.2.10-50"
}
],
The DENY_CHECKOUTS and DENY_BORROWS rules restrict the use of features to the specified users, so most of the users will still be able to use them. The syntax and keywords are the same as for allow rules.
Examples
A rule that denies features to selected users would look like this:
"DENY_CHECKOUTS": [
{
"FEATURES": "FUNCTIONALITY_ADVANCED_ANALYSIS;FUNCTIONALITY_TECHDOC",
"USERS": "Some user; Some other user; Another user"
}
],
A rule that denies the borrowing of EXPORT_ALL for the MEMBERS defined in a GROUP with the NAME "Borrowing denied" would look like this:
"DENY_BORROWS": [
{
"FEATURES": "EXPORT_ALL",
"USERS": "Borrowing denied"
}
],
...
"GROUPS" : [
{
"NAME": "Borrowing denied",
"MEMBERS": "Some user; Some other user; Another user"
}
]
To disable borrowing of a feature for all users, set USERS to *
or remove the value completely:
"DENY_BORROWS": [
{
"FEATURES": "EXPORT_ALL",
"USERS": "*"
}
],
To disable borrowing completely, set both FEATURES and USERS to *
:
"DENY_BORROWS": [
{
"FEATURES": "*",
"USERS": "*"
}
],
The LIMIT_CHECKOUT and LIMIT_BORROW rules are helpful for controlling the number of features that should be available to different user groups. They are also used to limit the borrowing duration of features. Their syntax is based on the allow and deny rules, with additional keywords:
Only for LIMIT_BORROW:
Examples
Restrict the usage of a feature within a group of users:
"LIMIT_CHECKOUTS": [
{
"FEATURES": "IMPORT_ALL",
"USERS": "User 1; User 2; User 3; ... ; User 30",
"COUNT": 15
}
],
Restrict the borrowing period of any feature to one week for all users, except one privileged user who is allowed to borrow for three months. This is accomplished by first increasing the default value to three months, and then restricting all users except the Privileged User:
"LIMIT_BORROWS": [
{
"HOURS": 2160
},
{
"EXCEPT_USERS": "Privileged User",
"HOURS": 168
}
],
The RESERVE_CHECKOUTS rule, unlike the limit rules, can be used to ensure that a certain number of features are always available to certain users. The syntax is the same as for allow rules, with the addition of the COUNT keyword.
Examples
Reserve a feature for three privileged hosts:
"RESERVE_CHECKOUTS": [
{
"FEATURES": "IMPORT_2D_ADVANCED",
"USERS": "HostX;HostY;HostZ",
"COUNT": 3
}
],
To ensure fail-safe licensing (e.g. server failures or updates), it is possible to set up redundant servers that can all serve the same licenses and features. The server addresses are defined like the value LicenseServerAddress in the client license 3DVS.lic:
"HAL_SERVERS": "6200@server01;6200@server02;6200@server03",
The order of the servers defines the priority of availability, so the first server should be the main server with the highest availability. If one server goes down, the next one in the list will take over as long as the other one is unavailable. The Borrow functionality is only available on the main server and will be unavailable during the downtime of the main server. Our HAL configuration supports two or more servers, the standard is three.
This setting allows you to customize the columns in the client overview in the License Monitor. You can hide data you do not need. You can also change the order of the columns to suit your preferences. The configuration can be done separately for User View and Admin View. The format to use is as follows:
"CLIENT_OVERVIEW_COLUMNS_USER": "SESSION_INFO;USERNAME;FEATURES_FLOATING;FEATURES_BORROWED;BORROW_TIME",
"CLIENT_OVERVIEW_COLUMNS_ADMIN": "SESSION_INFO;USERNAME;HOSTNAME;IP_ADDRESS;FEATURES_FLOATING;FEATURES_BORROWED;BORROW_TIME",
The VS License Manager supports both version of the Internet Protocol (IPv4 or IPv6). Which one is preferred can be defined here:
"IP_VERSION": "IPv4",
The history data (maximum usage and denials) is updated frequently, but only every eight hours by default to reduce server load. This can be changed in the preferences:
"HISTORY_UPDATE_HOURS": 8,
Similar to the log file archive cleanup, it is possible to automatically remove old history data. This includes only real-time data, which occupies most of the history data space. This setting is disabled by default:
"HISTORY_ARCHIVE_COUNT": 0,
To ensure a continuous network connection from the clients to the server, VS License Manager uses heartbeats. The following settings are for troubleshooting network traffic and server load issues only.
In the configuration file, these values will look like the following:
"HEARTBEAT_SECONDS": 140,
"TIMEOUT_SECONDS": 300,
"HEARTBEAT_CONTROL_SECONDS": 3,
The License Monitor, the web interface of the VS License Manager, can be accessed via a web browser: <LicenseServerAddress>:<HTTP_PORT>. It displays license information, feature availability and usage, and connected clients. The License Monitor is automatically refreshed every 60 seconds to keep it up to date.
With the configurated Admin Password it is possible to access an extended version of the License Monitor with the last log messages, the configuration settings and a section to visualize the checkout history via charts. These tabs do not reload automatically.
If required, access to the basic License Monitor can be completely restricted by setting a Main Password.
The VS License Manager stores data locally about how many features are used over time and by which users. In addition to a real-time view of the feature usage for the current day, there are preconfigured charts for hourly usage of the last 24 hours, daily usage of the last 30 days, monthly usage of the last 12 months and daily denied users for the last 30 days. It is also possible to create custom charts for individual time periods.
Usage data is stored in the installation directory under /data/History/. The data is stored in CSV format and can be easily used for further analysis. The columns are time (seconds since 01.01.1970), count, feature, username and errorcode.