HLServer: Server Install

From Headus Docs

(Difference between revisions)
Jump to: navigation, search
Revision as of 10:39, 12 April 2010 (edit)
Headus (Talk | contribs)
(By Client Side Groups)
← Previous diff
Current revision (04:08, 15 January 2014) (edit) (undo)
Headus (Talk | contribs)
(Removing all content from page)
 
(9 intermediate revisions not shown.)
Line 1: Line 1:
-{{:HLServer: Menu}} {{TOC}} To correctly install and run hlserver you should follow these steps: 
-# Install the hlserver files. See below for OS specific instructions. <br><br>  
-# Using the sample provided, create hlserver.conf. You should at least change the IP range for "GROUP lan" to reflect your local setup. See below for an explanation of the hlserver config file. <br><br>  
-# Put the keys provided into .keys (Linux/OS X) or keys.txt (Windows). See below for an explanation of the key strings. <br><br>  
-# Start hlserver up. See the following chapter, [[HLServer: Running the Server|Running the Server]] for OS specific instructions. <br><br>  
-# Pass on to your users the information in [[HLServer: Application Config|Application Config]] so they can configure their software installs to access the floating license server.  
- 
-If your users encounter any problems accessing the floating licenses, 
-see 
-[[HLServer: Trouble Shooting|Trouble Shooting]] 
-for steps you can follow to track down the problem. 
- 
-== Linux Install == 
- 
-Typically you'll want be '''root''' and extract the TGZ file into '''/usr/local''' though that's not a strict requirement. 
-If you install into somewhere other than /usr/local/hlserver, you'll need to change the HEADUS_HOME variable in hlserver.run. 
- 
-{{warning|Previous Linux installs of HLServer extracted to '''/usr/local/''headus''''', and were split across the '''etc''' and '''lib''' sub-directories, but now all files are in the single '''hlserver''' directory. If you are upgrading, copy your old config and keys file to the new directory, and update or replace your init.d hlserver.run script.}} 
- 
-{{warning|HLServer uses '''/usr/tmp''' to save a PID file when running. If '''/usr/tmp''' doesn't exist, then HLServer may start, but will exit soon after. Creating a symbolic link from '''/tmp''' to '''/usr/tmp''' will fix this problem.}}  
- 
-The following files make up the Linux license server installation: 
- 
-<ul> 
- 
-; hlserver : This is the server application. It need not be run with any special privileges unless the PORT used (see below) is under 1027.  
- 
-; hlserver.conf : The contents of this file, explained in detail below, controls the behavior of the server.  
- 
-; hlserver.log : This is a series of date stamped log messages from the server showing, amongst other things, who is grabbing which licenses.  
- 
-; hlserver.redhat : This is a RedHat/Fedora script that can be used to start the server on boot, and stop it on shutdown. Installation instructions are in the file.  
- 
-; hlserver.debian : Start/stop script for Debian/Ubuntu based systems. Installation instructions are in the file.  
- 
-; hlmanager : This is the manager application. See "The Manager" chapter for details.  
- 
-; .keys : This file holds the floating license keys.  
- 
-</ul> 
- 
-== OS X Install == 
- 
-Select or create a new user that will be used to run the hlserver daemon. Login as that user, open up a shell window, extract the TGZ file into a temporary directory, change to that directory and run the setup script ... 
- 
- tar xvfoz hlserver-osx-??????.tgz --directory=/tmp 
- cd /tmp/hlserver 
- ./setup 
- 
-First you'll be asked to edit the config file. If you are familiar with '''vi''', then run 'vi hlserver.conf' from the shell window. If you prefer to use Finder, double click '''hlserver.conf'''; if prompted for an editing application, select '''TextEdit'''. You should at least change the IP range for "GROUP lan" to reflect your local setup.  
- 
-Re-run the setup script and the keys file is checked. If you have your license keys already, cut'n'paste them into the '''sample-keys''' file, otherwise email the 5 code strings to your vendor for some license keys. As with the config file above, you can either use '''vi''' from the shell window, or '''TextEdit''' from Finder, to edit the sample keys file. Once the keys are in the sample keys file, use the shell window to rename it to '.keys' ... 
- 
- mv sample-keys .keys 
- 
-Re-run the setup script and you'll be asked for an installation location. By default the script will want to put the binaries and config files into '''/usr/local/hlserver''', but you can type in a different path at the prompt if you wish. 
- 
-If the setup script runs smoothly, hlserver will be started and hlmanager is run as a final check. You should see something like the following as output ... 
- 
- Waiting for HLServer to start ... 10 9 8  
- Trying HLManager ... 
- Trying architec@localhost ... 
- Server localhost up 4 seconds 
- <--------- Licenses ----------> <------------------------- Users -------------------------> 
- Name Status Free Used Id Hostname User App Age Idle  
- uvlayoutv2 29 days 4 0 
- 
-hlserver will be automatically restarted whenever the system is rebooted, and you can stop and start it via the '''launchctl''' command. 
- 
-The following files make up the OS X license server installation: 
- 
-<ul> 
- 
-; hlserver : This is the server application.  
- 
-; hlserver.conf : The contents of this file, explained in detail below, controls the behavior of the server.  
- 
-; hlserver.log : This is a series of date stamped log messages from the server showing, amongst other things, who is grabbing which licenses.  
- 
-; hlmanager : This is the manager application. See "The Manager" chapter for details.  
- 
-; .keys : This file holds the floating license keys.  
- 
-</ul> 
- 
-== Windows Install == 
- 
-Login as a user with 
-'''Administrator''' 
-privileges, and run the EXE file. 
- 
-The following files make up the Windows license server installation: 
- 
-<ul> 
- 
-; hlserver.exe : This is the server application. It need not be run with any special privileges unless the PORT used (see below) is under 1027.  
- 
-; hlserver.conf : The contents of this file, explained in detail below, controls the behavior of the server.  
- 
-; hlserver.log : This is a series of date stamped log messages from the server showing, amongst other things, who is grabbing which licenses.  
- 
-; hlserver.ini : Edit this file to change the server start-up command line arguments.  
- 
-; hlmanager.exe : This is the manager application. See "The Manager" chapter for details.  
- 
-; keys.txt : This file holds the floating license keys.  
- 
-</ul> 
- 
-== Configuration == 
- 
-The config file is used to control access to the server and 
-licenses. The simplest config file looks like this: 
- 
-<pre> 
-PORT 11668 
-LOG 1 
-ACC 0 
-IDLE 0 
-  
-GROUP lan 192.168.0.* 
-GROUP Manager root@lan 
-  
-PRODUCT cyslicev3 lan 
-</pre> 
- 
-<ul> 
- 
-; '''PORT''' : The server will listen at this port for license requests. There is no restriction on what this number is apart from the obvious one, that it doesn't conflict with ports used by other installed software. If you have a firewall running on the server, then you will need to open up access to this TCP port. 
- 
-; '''LOG''' : Set the level of verbosity of the log files.  
- 
-; '''ACC''' : Set the level of access to '''hlmanager''' for normal users. See [[HLServer: The Manager#User Mode|The Manager: User Mode]] for details. 
- 
-; '''IDLE''' : Number of hours to wait before killing idle TCP/IP connections. Idle connections will occur if a user hibernates or suspends their PC when a license is checked out, or the workstation or network has died, and can result in "zombie" licenses being checked out but not actually used by anyone. 20 hours is probably a safe value, allowing people to legitimately suspend their PCs over night, while also cleaning out zombie licenses at least once a day. Setting this value to "0" turns off the idle connection kill. '''''Linux servers only.''''' 
- 
-; '''GROUP''' : Each line of this section associates a single name with a list of hosts, prefixed with optional user names. In the above simplest case, '''lan''' is associated with the IP range for a local area network. The name '''lan''' can then be used to refer to all hosts in the LAN. 
-; : The '''*''' character is a shorthand way of saying '''1-255'''; they both mean the same thing. The '''*''' character can also be used to extend to the beginning or end, as in '''45-*''' (equivalent to 45-255) or '''*-66''' (equivalent to 1-66).  
- 
-; : The brace characters can be used to surround a list of alternatives, as in '''{*-45,47,49-*}''' (everything except 46 and 48).  
- 
-; : Hostnames can be used in place of IP ranges, though the list could become quite long if you are serving a large number of hosts. IP ranges are more concise, and will avoid any possible domain name resolution problems.  
- 
-; : The special group '''Manager''' defines the list of users that can be trusted to run the hlmanager application (see "The Manager" chapter for more details).  
- 
-; : {{warning|Usernames are case-sensitive, so the default Windows hlserver.conf, with "GROUP Manager Administrator@lan", wont give access to a user with an "administrator" login.}} 
- 
-; : By the way, there's nothing stopping you from defining '''*.*.*.*''' as an IP range. The advantage of this is you don't have to think, but the disadvantage is that anyone who has access to your license server can grab one of your floating licenses. This includes anyone, anywhere in the world, if the server is connected to the internet.  
- 
-; '''PRODUCT''' : In this section you should have a single line for each product that you have floating keys for. Follow the license name with a list of hostnames or group names that have access to that product. You can optionally prepend a username, in the form '''username@host/groupname''' to further restrict access. If a Windows username has spaces in it, replace those with underscore in the config file (e.g. login "Jill Smith" would need to be written as "Jill_Smith" in the config file). 
- 
-</ul> 
- 
-The following shows a more complex example of a config file. 
-<pre> 
-PORT 11668 
-LOG 1 
-ACC 1 
-IDLE 6 
- 
-GROUP cg-lab 192.168.0.1-23 
-GROUP office fred,barney 
-GROUP offsite 112.56.22.{12-15,21} 
-GROUP Manager julie@office,jimbo@cg-lab,root@hlserver 
-  
-PRODUCT cyslicev3 cg-lab,{phil,jill}@offsite 
-PRODUCT plyedit jimbo@cg-lab 
-</pre> 
- 
-Anyone currently logged into a  
-'''cg-lab''' 
-machine can request a cyslicev3 license, but only  
-'''phil''' 
-or 
-'''jill''' 
-can from the handful of  
-'''offsite''' 
-machines. 
-Whenever  
-'''jimbo''' 
-is logged into a  
-'''cg-lab''' 
-machine, he can request a cyslicev3 or plyedit license as well as run 
-the license manager. 
- 
-== Keys == 
- 
-Floating licenses, stored in the 
-'''.keys''' 
-or 
-'''keys.txt''' 
-file, look something like this: 
-<pre> 
- Products System Expire Num 
- # uvlayoutv2 sysid=690ca1ab expire=101226 [000 4] 
- 8MFP LCDY A0GZ 553N QQ6Z BLMB A1A6 GF1G # 6200 
- 74QX SEPD GEC4 AK1W QJK8 3E5N 2LLF 345C JQX5 24SA # 6201 
-</pre> 
- 
-You might also have the older style license keys that look like this: 
-<pre> 
- <- 21 hex numbers -> Product System Expire Ref# Num 
- #v2# 3a d6 ........ a9 42 # cysurf 690ca1ab never 0920 [001 3] 
- #v2# 5d da ........ 32 6a # cyslicev3 690ca1ab never 0921 [001 1] 
- #v2# 37 db ........ 71 5b # cyslicev3 690ca1ab 110216 0922 [002 1] 
-</pre> 
- 
-The 
-'''Product''' 
-names go into the config products section, 
-'''System''' 
-is the sysid of the license server, 
-'''Expire''' 
-is when each floating license runs out,  
-'''Ref#''' 
-is a database reference number used by the issuer, and 
-'''Num''' 
-is the sequence id and number of floating licenses in that key. 
- 
-In the first example there are 4 '''uvlayoutv2''' floating licenses. 
- 
-In the second example above, there is 1 
-'''cyslicev3''' 
-and 3 
-'''cysurf''' 
-floating licenses that will never expire, and 1 additional 
-'''cyslicev3''' 
-license that runs out on the 16th of Feb, 2011. Even though there are 
-multiple cyslicev3 keys, you would normally only have one cyslicev3 access 
-list in the config products section. 
- 
-== Partitioning == 
- 
-<font color=green>Requires hlserver v1.15+.</font> 
- 
-In the examples shown to this point, all licenses for a particular product are available to all the users listed on the '''PRODUCT''' line. For example, in the following config file all of the '''uvlayoutv2''' licenses are available to everyone from '''cg-lab''' and '''offsite''': 
- 
-<pre> 
-GROUP cg-lab 192.168.0.1-23 
-GROUP offsite 112.56.22.{12-15,21-*} 
-  
-PRODUCT uvlayoutv2 cg-lab,offsite 
-</pre> 
- 
-With ''partitioning'', you can allocate a different number of licenses to the different groups. In the following example, '''10''' licenses in total are available (this is determined by your license keys), but '''7''' have been reserved for users from '''cg-lab''', and '''3''' for '''offsite''' users: 
- 
- PRODUCT uvlayoutv2 cg-lab<font color=green>'''[7]'''</font>,offsite<font color=green>'''[3]'''</font> 
- 
-The number inside the square brackets defines the number of licenses allocated to that group. In the above example, if a fourth '''offsite''' user tries to grab a license, they will be denied access, even if none of the cg-lab licenses have been used. 
- 
-You can also choose to restrict some groups but not others. In the following example, '''offsite''' users are restricted to '''3''' licenses maximum, but '''cg-lab''' users could grab all of the '''10''' licenses if they are free. 
- 
-<pre> 
-PRODUCT uvlayoutv2 cg-lab,offsite[3] 
-</pre> 
- 
-Another way to define the above partitioning is via the use of negative allocations. In the following example, '''offsite''' users can have all but '''7''' of them, or in other words, '''cg-lab''' users are guaranteed to have at least '''7''' licenses: 
- 
-<pre> 
-PRODUCT uvlayoutv2 cg-lab,offsite[-7] 
-</pre> 
- 
-=== By License Key Groups === 
- 
-You can also partition according to license key groups. In the following keys file there are two groups, a pair of permanent keys with an ID of '''000''', and 4 temp keys with an ID of '''001'''. You can find this information inside the square brackets: 
- 
- # hlserver,uvlayoutv2 sysid=5b83f8dd expire=perm <font color=green>'''[000 2]'''</font> 
- R6LZ PF0Q HZ65 8H55 463T E69W 07WF 5R9C # 10395 
- NTRC 4H24 5R9C 1KZF RJ0Y C0CW 8H55 G1SE 76GZ F6AA # 10396 
- # uvlayoutv2 sysid=5b83f8dd expire=100602 <font color=green>'''[001 4]'''</font> 
- F913 2LLB 71WC 71FG PF0Q XYPL WAYH HCTQ D7PA 6RAA # 10398 
- 
-To allocated each of the key groups to different groups within the config file, create multiple '''PRODUCT''' lines and append the key group ID to the product name, separated by a period character. In the following example, users from '''cg-lab''' are allocated the 2 permanent keys, and users from '''offsite''' get the 4 temporary keys: 
- 
- PRODUCT uvlayoutv2<font color=green>'''.000'''</font> cg-lab 
- PRODUCT uvlayoutv2<font color=green>'''.001'''</font> offsite 
- 
-You can combine all partitioning methods if you wish. In the following example, users from '''cg-lab''' are guaranteed their 2 permanent key, but can also grab up to 2 of the temporary keys if they are free. 
- 
- PRODUCT uvlayoutv2.000 cg-lab 
- PRODUCT uvlayoutv2.001 offsite,cg-lab[2] 
- 
-=== By Client Side Groups === 
- 
-<font color=green>Requires hlserver v1.16+.</font> 
- 
-In some environments, such as those using DHCP to assign IPs, partitioning using a static list of IP addresses is not feasible. You might then use usernames to control access, but if people are regularly being moved between projects with different access rights, keeping the config file in sync can be a hassle. In these cases you can use client side groups to control access. 
- 
-In the following example, two groups are defined with the exact same IP ranges, and then access to the two products is partitioned according to the two group names: 
- 
-<pre> 
-GROUP teamA 192.168.0.* 
-GROUP teamB 192.168.0.* 
-  
-PRODUCT uvlayoutv2 teamA 
-PRODUCT cyslicev3 teamB 
-</pre> 
- 
-Just by itself, this config would allow all users access to both products, so what you also need to do is allocate users to their groups on the client side via the '''HEADUS_HLGROUP''' environment variable. In the above example, setting the value of HEADUS_HLGROUP to "teamA" would then allow that user to access the "uvlayoutv2" licenses only. 
- 
-Under Windows, 'Group Policy Objects' can be used to assign HEADUS_HLGROUP definitions to each user. 
- 
-{{TOP}} 

Current revision