[ Platform Documentation ] [ Title ] [ Contents ] [ Previous ] [ Next ] [ Index ]
Once LSF desktop support is installed, it is designed to run out of the box. You need to specify very few parameters to begin using the LSF desktop support. However, you may need to periodically update configuration parameters for the desktop clients.
- Configuring Desktop Clients
- Configuring Platform LSF Desktop Support High Availability
- Configuring EGO Management of Platform LSF Desktop Support Services
- Changing Job Completion Log Location
- Setting Up Licensing
- Configuring the Default LSF Desktop Support Queue
- Creating an Additional LSF Desktop Support Queue
- Desktop Server Configuration Settings
- Supporting Desktop Client Resource Requirements
- Adding New Resources to the Desktop Server
- Adding a Resource Plug-In to the Desktop Clients
- Entries in wscache.conf for Desktop Servers
- Entries in wscache.conf for Directory Services Server
- Adding an LSF Desktop server to your cluster
- Configuring Windows Group Policies to Define Security Settings for SED
[ Top ]
Configuring Desktop Clients
When you want to change the configuration of all of the desktop clients, you can edit the desktop client configuration file,
SEDConfig.xml
.
SEDConfig.xml
is located on the directory service server in the directory specified by theCONFIGDIRECTORY
value ininstall.config
. You can use an XML editor or a text editor such as vi to modify this file.Each desktop client in the LSF desktop support environment reports to the desktop server on startup and once every 24 hours, checking for an updated configuration. If the desktop client detects a new version of the configuration, it downloads the new configuration file and applies it.
You can configure the following options for desktop clients:
- Changing the time between work requests from an idle desktop client
- Setting the time period for which a desktop client pauses
- Updating desktop client applications with a new version
- Changing the Directory Services host
- Ensuring full cleanup on an Windows desktop client
- Setting the conditions for a desktop client requesting work
- Specifying the interval to check for configuration changes
- Setting conditions for jobs running on battery power
- Specifying whether desktop clients can write to the cache
- Enabling file caching on the desktop client
Example: SEDConfig.xml
<?xml version="1.0"?> <SEDConfig> <MEDDSURL>http://dirservhost.platform.com/servlet/DynamicSEDConfig</ MEDDSURL> <MEDURL>http://dirservhost.platform.com/servlet/SedSoap</MEDURL> <SEDFullyKillNTJob>yes</SEDFullyKillNTJob> <SEDPollInterval>300</SEDPollInterval> <SEDLatestVersion>41</SEDLatestVersion> <SEDLatestVersionURL>http://dirservhost.platform.com/SED/sedupd.exe </SEDLatestVersionURL> </SEDConfig>Changing the time between work requests from an idle desktop client
Edit the
SEDPollInterval
parameter inSEDConfig.xml
:<SEDPollInterval>300</SEDPollInterval>To change the amount of time between requests for work from an idle desktop client, specify the time the desktop client waits before requesting another job or reporting status in seconds. The default is 300 seconds, which is five minutes.
Setting the time period for which a desktop client pauses
Edit the
SEDOptOutInterval
parameter inSEDConfig.xml
to specify the number of seconds for which the desktop client pauses. At the end of this time period, the desktop client starts processing again.Specify the time period as follows:
<SEDOptOutInterval>ssssss</SEDOptOutInterval>where ssssss is the number of seconds. For example, to pause the desktop client for 2 hours, specify 7200 seconds.
Updating desktop client applications with a new version
Note: Thesedupd.exe
file is included with patch kits.
Edit the following parameters in
SEDConfig.xml
:
- Use the
SEDLatestVersionURL
parameter to specify the host name in the URL where the desktop client will go to get a new version of its binary, during an automatic upgrade of the desktop client. The URL can be any URL that supports the http GET method. Specify the URL as follows:<SEDLatestVersionURL>http://dirservhost.platform.com/ SED/sedupd.exe</SEDLatestVersionURL>- Use the
SEDLatestVersion
parameter to specify the exact version number of the new desktop client software. This tells the desktop client to look for that new version of its binary. Specify the value as follows:<SEDLatestVersion>41</SEDLatestVersion>To find your current version number, see
sed.log
.Changing the Directory Services host
Edit the MEDDSURL parameter in
SEDConfig.xml
to specify the host name in the URL pointing to the updated configuration file. Specify the URL as follows:<MEDDSURL>http://dirservhost.platform.com/servlet/DynamicSEDCo nfig</MEDDSURL>
Do not change other values in the URL other than the host name (dirservhost.platform.com).
All desktop server host names must be included in the
MED.lst
file. The location of this file is specified by the CONFIGDIRECTORY parameter ininstall.config
. If CONFIGDIRECTORY is not defined, the default location is$ACH_TOP/config
.The dynamic Web page reads the
MED.lst
file and returns the name of an desktop server in the MEDURL field of the XML file. The desktop client then uses this desktop server until the next reconfiguration.Ensuring full cleanup on an Windows desktop client
When a job completes on an Windows desktop client, some child processes associated with the job may still be running. You can enable an option to kill all processes associated with
seduser
(or the user account that runs the jobs) when a job completes, using theSEDFullyKillNTJob
option. By default, this option is not enabled.Edit the
SEDFullyKillNTJob
parameter inSEDConfig.xml
. Change the value fromno
toyes
as follows:<SEDFullyKillNTJob>yes
</SEDFullyKillNTJob>
Warning: Make sure that the user account under which LSF desktop support jobs run on Windows is not a real end-user's account--the user's processes could also be killed when the Windows job completes.
Setting the conditions for a desktop client requesting work
Specify the circumstances under which a desktop client requests work
Set the
SEDMode
parameter inSEDConfig.xml
to one of the following values:
- Always: Jobs can always run, even if an interactive user is signed on to the desktop client.
- Logon: Jobs can run only when no user is logged on to the desktop client. A user is logged on during an interactive session that is initiated from a Windows logon dialog box. If a job is running when an interactive user logs on, the job is terminated and the desktop server is notified of the termination. The desktop server then redispatches the job.
- Screensaver: Jobs can run only when a screen saver is active. If a job is running when the screen saver becomes inactive, then the job is suspended.
When the screen saver becomes active:
- Idle: Jobs can run only when the desktop client has been idle for a configurable period, determined by
SEDConsoleIdle
, as described in Specify the period of inactivity before the desktop client can request work. If a job is running when the desktop client stops being idle, then the job is suspended.When the desktop client becomes idle:
If no valid value is specified, then the default value of Screensaver is used.
For example:
<SEDMode>Logon</SEDMode>
Determine whether the desktop client mode is configurable by individual desktop client users
Use the
SEDModeSelectableByUser
parameter inSEDConfig.xml
to determine whether the desktop client mode (defined by the value of theSEDMode
parameter, described above,) is configurable by individual desktop client users.
- No: The value of
SEDMode
inSEDConfig.xml
is used by all desktop clients.- Yes: The value of
SEDMode
inSEDConfig.xml
is ignored. This uses the value specified by the user in the desktop client configuration.Valid values are
yes
orno
. Otherwise, the default value is used. Default value isyes
(case insensitive).Specify the period of inactivity before the desktop client can request work
Use the
SEDConsoleIdle
parameter inSEDConfig.xml
to specify the period of keyboard or mouse inactivity in seconds before the desktop client can request work. This is relevant only if theSEDMode
parameter, described above, is specified asIdle
.The default is
900
seconds (15 minutes). Any integer above 300 seconds is a valid value. Otherwise, the default value is used, and a warning is logged in the SED log file.Changes to the above configuration parameters take effect only when the desktop client next checks the desktop server for configuration changes. By default, this check occurs every 24 hours. You can use the
SEDUpdateCheckInterval
parameter inSEDConfig.xml
to configure this interval, as described below, in Specifying the interval to check for configuration changes.Specifying the interval to check for configuration changes
Edit the
SEDUpdateCheckInterval
parameter inSEDConfig.xml
to specify, in hours, the interval at which the desktop client checks the desktop server for configuration changes. The default value is 24 (hours).Note that the desktop client only checks for configuration changes if it is idle, i.e. if it is not currently running a job. If the desktop client is not idle when the check is scheduled to occur, it occurs the next time the desktop client becomes idle.
Setting conditions for jobs running on battery power
Edit the
SEDSuspendOnBattery
parameter inSEDConfig.xml
to indicate whether jobs can run if the desktop client is running on a machine using battery power (e.g. a laptop computer). If this parameter is set to Yes, then if the desktop client switches to battery power:
- Any running job is terminated and the desktop server is notified of the termination
- The desktop client cannot start running jobs
Specifying whether desktop clients can write to the cache
Edit the
SEDDisableCache
parameter inSEDConfig.xml
to indicate whether the desktop client can write to the cache. Valid values are yes, true, false, and no (the default), case insensitive.
yes
ortrue
indicates that the desktop client does not write to the cache, however it still retrieves valid files from the cache.no
orfalse
indicates that the desktop client writes to the cache. However, when submitting a job, the user can disable writing to the cache for a specific file. For additional information, refer to the Platform LSF Desktop Support User's Guide.
Note: TheLSB_MED_CACHEFILE_DEFAULT
parameter inmed.conf
specifies the default file caching setting for all desktop clients connecting to a specific desktop server. For additional information, see Desktop Server Configuration Settings and refer to the Platform LSF Desktop Support User's Guide.
Enabling file caching on the desktop client
The desktop client transparently uses Microsoft Internet Explorer's cache to upload and download files. In Windows 2000, Windows 2003 Server, and Windows XP, the desktop client runs as the LocalSystem account. Therefore, for each desktop client user, you need to specify:
- Write permissions
- Caching policy, i.e. under which circumstances, if any, LSF desktop support obtains files from the cache
- The size of the cache folder
Note: Changing any of these settings requires restarting the desktop client to take effect.
For detailed instructions on changing these settings, see Enabling Caching on the Desktop Client.
[ Top ]
Configuring EGO Management of Platform LSF Desktop Support Services
You can configure EGO management of the master execution daemon (
MED
) and the Web server components (Tomcat and Apache) so that they run as EGO services. This enables automatic startup of these services, which improves availability.
EGO must be enabled in the LSF cluster to configure EGO management of LSF desktop support services. See Administering Platform LSF for information about enabling EGO for LSF.
About EGO management of LSF desktop support services
With EGO management of LSF desktop support services enabled, you can
- Enable automatic restart of the
MED
, Tomcat, and Apache services- Use EGO commands to view the status of EGO services, including LSF desktop support services
- Use EGO commands to start LSF desktop support services
Configuring EGO management of LSF desktop support services provides additional high availability in cases where the
MED
or Web services fail during job execution. EGO can restart the services, which prevents rerunnable jobs from wasting valuable CPU time by rerunning unnecessarily.In the following examples, the term
MED/WS
refers to the master execution daemon and web server processes running on a Platform LSF desktop support server.Without EGO management of LSF desktop support services (feature not enabled): Web service
With EGO management of LSF desktop support services enabled: Web service
Without EGO management of LSF desktop support services (feature not enabled): MED
With EGO management of LSF desktop support services enabled: MED
Scope and Limitations
EGO management of LSF desktop support services applies to the
MED
and to the Web servers (Tomcat and Apache). With EGO management of LSF desktop support services enabled, you should not use the commandlsfac_daemons
to start or stop Apache or Tomcat services. Instead, you should use theegosh
command to start and stop these services.Configuration to enable EGO management of LSF desktop support services
Enable EGO management of the MED
Configuration file Parameter and syntax Behavior lsf.conf
LSF_EGO_DAEMON_CONTROL= Y
Enable EGO management of LSF desktop support Web services
During installation, the files
LSFDesktopApache.xml
andLSFDesktopTomcat.xml
are created in the directory$AC_TOP/config
, using the correct variable values. To enable EGO management of LSF desktop support Web services, you must copy these files and increase the number of available slots to accommodate the two additional services (Apache and Tomcat) managed by the EGO Service Controller.
- Copy
LSFDesktopApache.xml
andLSFDesktopTomcat.xml
to EGO_ESRVDIR/esc/conf/service
- Increase the availableSlots in the
InternalResourceGroup
by 2, as shown in the following example.
Configuration file Parameter and syntax LSF_CONFDIR/ego/
cluster_name/ ResourceGroup.xml
<ResourceGroup ResourceGroupName="InternalResourceGroup" availableSlots="5"/>
To add the new services, you must restart EGO using the command
egosh ego restart all
. See Administering and Using Platform EGO.
[ Top ]
Configuring Platform LSF Desktop Support High Availability
The high availability feature provides a way to maximize CPU usage by ensuring that successfully completed rerunnable jobs run only once, even if master execution daemon (
MED
) and Web server (WS
) processes fail during job execution. With high availability enabled, client hosts can upload job results to a new desktop server if they can no longer connect to the original desktop server.About LSF desktop support high availability
There are three key components of the Platform LSF desktop support high availability feature:
- A directory that functions as a job status pool for every job dispatched to a slave execution daemon (
SED
)- A job status file for each job, stored in the job status pool directory and removed when the job finishes or is killed
- At least one backup Directory Service to make sure that desktop clients (
SEDs
) can always access information about jobsWithout high availability (feature not enabled)
In the following description, the term
MED/WS
refers to the master execution daemon and web server processes running on a Platform LSF desktop support server.
With high availability enabled
Scope and behavior
The high availability feature applies only to jobs submitted as rerunnable, and when both the
MED
, thelim
, and one or more components of the associatedWS
fail. For cases where high availability does not apply, you can configure EGO to controlMED
, Apache, and Tomcat as services that EGO automatically restarts.In the following description, (ok) indicates that a process is running and (-) indicates that the process failed during job execution.
Configuration to enable the high availability feature
The high availability feature is configured for desktop servers (
MED
) inwscache.conf
and for desktop clients (SED
) inSEDConfig.xml.
You must configure both servers and clients.Before you enable the high availability feature:
- Create a job status pool directory with the following characteristics:
- Set up at least two Directory Service hosts
- In lsb.queues, for all LSF desktop support queues, define RERUNNABLE=
yes
To enable the high availability feature, you must define the following parameters.
To apply configuration changes to desktop servers, you must restart the Web services on all desktop server hosts. To apply changes to desktop clients, you can either restart all SEDs or let each SED automatically get the new values when the SED checks for configuration changes.
Configuration to modify the high availability feature
You can define the following optional parameter to modify the length of time a desktop server holds a job before dispatching the job to a new
SED
.
[ Top ]
Changing Job Completion Log Location
Each desktop server has a log file
job_completion_log
with a date stamp in the YYYY_MM_DD format in which daily job completion information is stored. For example:job_completion_log.
host_name.2001_12_31
The location of the log file is specified by the JOBDIRECTORY parameter in
wscache.conf
in the TOMCAT_HOME directory of each desktop server.Whenever a job is completed, a line is logged in the file. If no jobs are completed on a specific day, no file is created for the day. Each day has a separate log file.
Job completion log file format
TimeStamp|HumanReadableTime|JobID:rerun|SedID|ExitedCode|FailureCode| ElapsedTime|UserTime|KernelTimeFor example:
1010985060497|15/01/2002 14:30:15|123[34]:0|CR185119-B_886056_1|0|0|2908|0|7531
TimeStamp
--The difference, measured in milliseconds, between the current time and midnight, January 1, 1970 UTCHumanReadableTime
--Time in human readable format, dd/mm/yyyy hh:mm:ss
JobID
--ID of the job. If it is a job array, the format is JobID[index]. The number after the : indicates the number of times the job has been rerunExitedCode
,FailureCode
--Any non-zero value indicates a problemElapsedTime
--Job run time in secondsUserTime
,KernelTime
--UserTime+KernelTime=CPU Time
in secondsTo change the directory in which job log files are stored:
You can change the location where the log files are stored.
- On the desktop server, locate and open the file
wscache.conf
for editing. It is located in the TOMCAT_HOME directory.- To change the location where the job completion log files are stored, in the JOBDIRECTORY parameter, specify the full path for the directory. For example:
JOBDIRECTORY ACH_TOP/wscache
- Save the file.
[ Top ]
Setting Up Licensing
Make sure that you have the correct number of licenses for your desktop servers and your desktop clients.
To set up licensing:
- Contact Platform Technical Support to get authorization keys for the following:
- Follow the procedures in the Platform LSF Administrator's Guide to set up licenses for your desktop servers.
[ Top ]
Configuring the Default LSF Desktop Support Queue
The default LSF desktop support queue is AC_QUEUE, which is configured during the installation using the default options. Because LSF desktop support uses a subset of the standard LSF queue parameters, do not add to or delete parameters from this queue. If required, you can change the following values:
To configure the default queue:
- Find the default LSF desktop support queue AC_QUEUE in
lsb.queues
.- HOSTS parameter. Optional. You can change the desktop server host name for this queue as follows:
HOSTS=host_name
- RUNLIMIT parameter. Optional. If you want to change the amount of time that a job in this queue can run before the job is terminated automatically, specify the following:
RUNLIMIT = [hh:mm] maxhh:mmwhere maxhh:mm is the maximum run limit allowed, and hh:mm, if specified, is the default run limit for the queue. The default is 120 10000000, which sets the default run limit to 2 hours and the maximum to 10 million minutes.
Note: The value ofRUNLIMIT
in the queue is scaled based on the CPU factor of the execution host. In Platform LSF desktop support, it is scaled by the speed of the desktop server rather than by the speed of the desktop client. Therefore, in the queue, you should setDEFAULT_HOST_SPEC=pc_host_model
. For additional information refer to the Platform LSF Reference.
- SWAPLIMIT parameter. Optional. If you want to change the total virtual memory that a job in this queue can use before the job is terminated automatically, specify the following:
SWAPLIMIT = nnnnwhere nnnn is the maximum number of kilobytes. The default is 102400, or 100 MB.
- AC_RES_REQ parameter. Optional. If you want to specify desktop client resource requirements that apply to all jobs submitted to this queue, specify a resource requirements statement using this parameter. For example:
AC_RES_REQ=cput==PII&&mem>128The above states that all jobs submitted to this queue require a Pentium II processor with more than 128 megabytes of free physical memory. See Built-in resource definitions for the possible values you can specify for resources.
- STOP_COND parameter. Optional. If you want to stop a job and submit it to a different desktop client if the available memory on the desktop client drops beneath a certain threshold, you can set the threshold level here using the STOP_COND parameter. The only accepted threshold is mem. For example:
STOP_COND=mem<50- RERUNNABLE parameter. Optional. If yes, enables automatic job rerun (restart). Rerun is disabled when RERUNNABLE is set to no. The yes and no arguments are not case sensitive.:
- Run
badmin reconfig
tor
econfigure mbatchd.[ Top ]
Creating an Additional LSF Desktop Support Queue
If you want to use multiple queues in your LSF desktop support, make sure that the queues you create are LSF desktop support-compatible. LSF desktop support supports a limited set of LSF queue parameters. Therefore the recommended method for creating an additional queue is to copy the queue created by the install script.
To create an additional queue:
- Find the default LSF desktop support queue AC_QUEUE in
lsb.queues
.- Copy AC_QUEUE. You can edit the new queue, but do not delete or add any parameters to the queue. The default queue contains all of the valid parameters for an LSF desktop support queue.
- QUEUE_NAME parameter. Required. Change the name of the queue as follows:
QUEUE_NAME = newnameSpecify any ASCII string up to 40 characters long. You can use letters, digits, underscores (_) or dashes (-). You cannot use blank spaces, and you cannot use the reserved name default.
- Specify the remaining parameters as described in Configuring the Default LSF Desktop Support Queue.
- Run
badmin
reconfig
to reconfigure mbatchd.[ Top ]
Desktop Server Configuration Settings
The desktop server configuration file
/etc/med.conf
contains the URLs required by the desktop server and the desktop clients for file and data transfer, and for status reporting.When you installed the desktop server, the install script
install.config
configured the desktop server for you. A description of each of the parameters is included here to help your understanding of the configuration.
Do not change the values in this file. To change the values, edit the install script and reinstall the desktop server.
About med.conf parameters
The following parameters are defined within
med.conf
:
- LSB_MED_WEB_URL parameter specifies the URL for the Tomcat Web server. This is where the host posts jobs waiting to be run. For example:
http://AChost/servlet/P2PServerwhere AChost is the desktop server name.
- LSB_MED_DATA_WEB_URL parameter specifies the URL for the file transfer location, where the desktop clients obtain any files required by the jobs they run. For example:
http://AChost- LSB_MED_STAGE_DIR parameter specifies the URL for the working files that contain job information. For example:
/usr/local/lsfac/apache/htdocs- LSB_MED_TOP_DIR parameter specifies the directory name where the desktop server is installed. For example:
/usr/local/lsfac- LSB_MED_SHARED_FILESYS parameter indicates whether a shared file system exists between desktop servers. The default is N (no). For example:
LSB_MED_SHARED_FILESYS=Y- LSB_API_CONNTIMEOUT parameter is used for MED communication with LSF mbatchd. The time-out in seconds when connecting to the Batch system. For example:
LSB_API_CONNTIMEOUT=60- LSB_API_READTIMEOUT parameter is used for MED communication with LSF mbatchd. The time-out in seconds when reading information from the Batch system. For example:
LSB_API_READTIMEOUT=120- LSB_MED_CACHEFILE_DEFAULT parameter is optional. Valid values are
yes
andno
, case insensitive. The default isyes
, which means that jobs can be cached on all desktop clients connecting to the specified desktop server. To prevent files from being cached on all desktop clients connecting to the specified desktop server, add the following line tomed.conf
after installation:LSB_MED_CACHEFILE_DEFAULT=No
Note: Desktop users can override this setting when submitting a job by using the + operator to instruct LSF desktop support to write a specific file to the desktop client cache. For example:bsub -f "local_file+ > remote_file"
. For additional information, refer to the Platform LSF Desktop Support User's Guide. To prevent files from ever being cached on the desktop client, set theSEDDisableCache
parameter inSEDConfig.xml
toyes
. For additional information, see Configuring Desktop Clients.
- USER_ID is the user ID of the USER_NAME parameter specified in
install.config
. The USER_NAME owns the Web server process. The default value of USER_ID isnobody
. If you change this value, you must restart the desktop server.- GROUP_ID is the group ID of the USER_NAME parameter specified in
install.config
. The USER_NAME owns the Web server process. The default value of GROUP_ID isnobody
. If you change this value, you must restart the desktop server.Example med.conf
LSB_MED_WEB_URL=http://host1/servlet/P2PServer LSB_MED_DATA_WEB_URL=http://host LSB_MED_STAGE_DIR="/usr/local/lsfac/apache/htdocs" LSB_MED_TOP_DIR=/usr/local/lsfac LSB_MED_SHARED_FILESYS=y LSB_API_CONNTIMEOUT=60 LSB_API_READTIMEOUT=120 USER_ID=99 GROUP_ID=99[ Top ]
Supporting Desktop Client Resource Requirements
LSF desktop support supports desktop client resource requirement specifications--the user can specify the minimum configuration of the desktop client required to run a particular job. Alternatively, you can set up LSF desktop support queues that define the minimum configuration required for all jobs submitted to that queue.
The desktop client resource types must first be defined to the cluster, and the desktop clients must be enabled to report on their resource availability before the user can successfully specify resource requirements.
LSF desktop support supports both built-in resource definitions and custom resource definitions. See Built-in resource definitions on this page for a list of the built-in resource definitions. See Adding New Resources to the Desktop Server for instructions on creating new resource definitions. See Resource requirement syntax for the syntax for defining the resources required, either within the queue definition, or within the job submission itself.
Built-in resource definitions
The following resource definitions are built in to LSF desktop support and available for use immediately:
The following CPU types are supported:
Resource requirement syntax
Specify the resource specification as a logical expression, as follows:
AC_RES_REQ=resource_name operator value[operator resource_name operator value...]resource_name
The name of the resource as defined in
ac.restype.xml.
operator
The operator that defines the relationship between the resource name and the value, or between nested expressions. The operators are listed below in the order of precedence (the order in which they are evaluated, from top to bottom). The operator can be one of the following:
value
The value of the resource to be compared to.
To specify multiple resources, combine specifications together using && or || combination operators. You can join specifications using brackets. For example:
"AC_RES_REQ=((cput==PII||mem>256)&&disk>500)"The above example specifies either a Pentium II CPU or 256 MB free physical memory, and 500 MB disk space available for LSF desktop support jobs.
[ Top ]
Adding New Resources to the Desktop Server
You can schedule jobs based on available resources. There are many resources built into LSF desktop support, but you can also add your own resources, and then use them in the usual way.
LSF desktop support provides powerful resource selection mechanisms, so that only the desktop clients with the required resources are allowed to run your jobs. For maximum flexibility, characterize your resources clearly, so that users can make the appropriate choices. For example, if some of your desktop clients are connected to both Ethernet and FDDI, while others are only connected to Ethernet, you probably want to define a resource called fddi and associate the fddi resource to desktop clients connected to FDDI. This way, users can specify the resource fddi if they want their jobs to run on desktop clients connected to FDDI.
To add new resources to a desktop server:
- Log in to the desktop server as the LSF desktop support administrator.
- Open the file
ac.restype.xml
for editing in an XML editor or in a simple text editor such as Notepad or Textpad. Specify a name and value type for the resource, by adding the following to the file:<Resource> <ResName>name</ResName> <ValueType>string</ValueType> </Resource>where name is the name of the resource you are defining, up to 16 characters in length, and ValueType is either
boolean
,string
ornumeric
. Resource names cannot begin with a number, and cannot contain any of the following characters:: . ( ) [ + - * / ! & | < > @ = ' "
Resource names are case-sensitive, and a resource name cannot be any of the following reserved names:
cput cpusp ncpus maxmem mem disk
Refer to Example: ac.restype.xml for an example of
ac.restype.xml.
- Save
ac.restype.xml.
- Create an external resource plug-in that detects the new resources for all desktop clients connected to that host. See To create an external resource plug-in: for instructions.
- Use one of the following methods to deploy the external resource plug-in to all the desktop clients connected to this host:
- Use a software-management tool that can deploy software in enterprise working environments to deploy the external resource plug-in to all the desktop clients. Deploy the plug-in to the same folder as
SED.exe
on the desktop clients.- Use the self-upgrade feature of LSF desktop support to deploy the external resource plug-in to all the desktop clients. See To build a distributable package for the plug-in: for instructions.
Example: ac.restype.xml
The following is an example of ac.restype.xml, where a new resource name hname is defined in addition to the built-in resource definitions:
<?xml Version="1.0"?> <ACRestype> <Resource> <ResName>cput</ResName> <ValueType>string</ValueType> </Resource> <Resource> <ResName>cpusp</ResName> <ValueType>numeric</ValueType> </Resource> <Resource> <ResName>ncpus</ResName> <ValueType>numeric</ValueType> </Resource> <Resource> <ResName>mem</ResName> <ValueType>numeric</ValueType> </Resource> <Resource> <ResName>maxmem</ResName> <ValueType>numeric</ValueType> </Resource> <Resource> <ResName>disk</ResName> <ValueType>numeric</ValueType> </Resource><Resource> <ResName>hname</ResName> <ValueType>string</ValueType> </Resource>
</ACRestype>[ Top ]
Adding a Resource Plug-In to the Desktop Clients
To add a new resource definition to LSF desktop support, you need to add the new resource name to
ac.restype.xml
. If you have not already done so, go to Adding New Resources to the Desktop Server to define the new resource. Then return here to add it to the desktop client plug-in.About the external resource plug-in
A desktop client supports only one plug-in, called
extRes.dll
. The plug-in must be in a Win32 dynamically-linked library. The plug-in must have two APIs called by the SED:BOOL WINAPI getExtRes(LPTSTR lpBUFFER[out], LPDWORD lpnSize[in|out]) int WINAPI getVersion()To create an external resource plug-in:
- Get the sample project of an external plug-in
extRes.dll
from ACH_TOP/plugin_example
.- Open the project with Visual C++ 6.0.
- Read the files to know how the sample works. Be sure to modify only the recommended files.
- Write a function to detect the new resource just like the sample function
detectDesktopName
.Make sure that you report the resource last. For example:
void detectDesktopName(CSEDExtRes* pClassExtRes) { TCHAR szDesktopName[256]={0}; DWORD cchBuff=256; GetComputerName(szDesktopName,&cchBuff); pClassExtRes->reptNewExtRes("hname","string", szDesktopName); }- In the function
reportAllResInfo()
, call your function:void reportAllResInfo(CSEDExtRes* pC;assExtRes) { detectDesktopName(pClassExtRes); detectIEVersion(pClassExtRes); detectOS(pClassExtRes); }- In the function
getVersion()
, set the new version number based on the last version number.To build a distributable package for the plug-in:
You can use this method to deploy the plug-in to the desktop clients using the automatic upgrade feature. Because the plug-in will be downloaded by the desktop client, you should have the upgraded binary file digitally signed by Platform Computing. Follow these steps to create the package:
- Send the upgraded
extRes.dll
to your Platform Support representative, who will sign and package it for you inpluginupd.exe
.- Copy
pluginupd.exe
to the same directory as that specified in PluginLatestVersionURL in APACHE_TOP/htdocs/SED/SEDConfig.xml
.- Set the permissions of
pluginupd.exe
to 755.- In the file
SEDConfig.xml
, in the PluginLatestVersion parameter, specify the exact version number of theextRes.dll
and save the file. Each desktop client will check periodically for a change in the version. When it detects a change, it does to the specified location and gets the new executable, which it installs automatically.[ Top ]
Entries in wscache.conf for Desktop Servers
The
wscache.conf
file is present on each desktop server and on the Directory Services host.The following parameter is present in the
ACH_TOP
/jakarta-tomcat-4.1.
30- LE-jdk14/wscache.conf
file of desktop servers.JOBDIRECTORY
The full path to the directory in which the internal state files of the system are stored.
JOBDIRECTORY /usr/local/lsfac/wscache[ Top ]
Entries in wscache.conf for Directory Services Server
The following parameters are present in the
wscache.conf
file of the Directory Services host.STATSDIRECTORY
The directory in which the job completion log files are stored. Job completion log files are named as follows:
job_completion_log.
host
_name
.
YYYY
-
MM
-
DD
STATSDIRECTORY /usr/local/lsfac/wscacheCONFIGDIRECTORY
The location where configuration for the directory service is stored. This entry does not exist if directory services are not enabled.
CONFIGDIRECTORY /usr/local/lsfac/wscacheJOBSTATISTICSURLS
Automatically generated value. Do not change. URLS generated by each desktop server indicating where data about the server can be retrieved.
BLACKLIST_POLL_INTERVAL
Specifies how frequently hosts on the block list connect to the desktop server to request work. For additional information and an example, see Controlling Desktop Client Access.
WHITELIST_POLL_INTERVAL
Specifies how frequently hosts on the whitelist connect to the desktop server to request work. For additional information and an example, see Controlling Desktop Client Access.
DEFAULT_POLL_INTERVAL
Specifies how frequently hosts on neither the blacklist nor the whitelist connect to the desktop server to request work. For additional information and an example, see Controlling Desktop Client Access.
FTDIRECTORY
Enables high availability for the desktop server. Specifies the absolute path to the directory that will contain the job status pool. Must be defined on every desktop server host. For additional information and an example, see Configuring Platform LSF Desktop Support High Availability.
FTOVERTIME
Specifies the amount of time in hours that the desktop server waits to receive job results from the SED. The desktop server waits the specified amount of time before redispatching the job to a new SED. If the original SED contacts the desktop server within the specified time, the job is not redispatched. The value must be an integer greater than zero. For additional information and an example, see Configuring Platform LSF Desktop Support High Availability.
[ Top ]
Adding an LSF Desktop server to your cluster
- Add a server host to your cluster, as described in Administering Platform LSF.
- Convert the new LSF server host to a desktop server.
See Converting the LSF Server Host to a Desktop Server in Installing LSF Desktop Support.
- If you are implementing automatic load balancing, add the new desktop server to file
MED.lst
.Each line is a server name. The path of this file is specified by the CONFIGDIRECTORY parameter in
install.config
.- To prevent desktop servers from running standard LSF jobs, see Excluding Desktop Servers from LSF Queues in Configuring the Components in LSF Desktop Support.
- Configure the Default LSF Desktop Support queue.
Edit the HOSTS parameter of AC_QUEUE to include the new desktop server.
- Update the LSF host configuration.
- Update the LSF resource configuration.
- Restart
lim
andmbatchd
.- Enable the client to use the new server:
[ Top ]
Configuring Windows Group Policies to Define Security Settings for SED
If you have
seduser
as a domain account, you can set permissions by defining Group Policy to apply to all desktop in the domain.The following example sets Group policy on a Windows 2003 server:
- Choose Start > Run, enter
mmc
to start the Microsoft Management Console, and click OK.- In the Console1 window, choose File > Add/Remove Snap-in.
- In the Add/Remove Snap-in dialog, click Add.
- In the Add Standalone Snap-in dialog, choose Active directory users and computers, and click Add.
- Close the dialog and return to Console1 window.
![]()
- Click + to expand Active Directory Users and Computers.
- Right click on the Organizational Unit (OU) you want to create a Group Policy Object for (for example,
testlab.com
), and select Properties.- Select the Group Policy tab.
![]()
- Select the Group Policy Object of your domain, and click Edit to open the Group Policy Object Editor.
- Expand Computer Configuration > Windows Settings > Security Settings > File System.
![]()
- Right click File System, and click Add File.
- In the Add a file or folder dialog, select a driver or folder where you want to set the permissions for
seduser
, and click OK.The Database Security dialog is displayed.
![]()
- In the Database Security dialog box, set the permissions of
seduser
for that driver or folder, and click OK.[ Top ]
[ Platform Documentation ] [ Title ] [ Contents ] [ Previous ] [ Next ] [ Index ]
Date Modified: January 29, 2009
Platform Computing: www.platform.com
Platform Support: support@platform.com
Platform Information Development: doc@platform.com
Copyright © 1994-2009 Platform Computing Corporation. All rights reserved.