Endpoint Configuration

You can configure an endpoint in the following ways:

• Implementing policy scripts for use by gateways and the endpoint manager
• Using lcfd command options and their values in the last.cfg file
• Specifying lcfd command options during endpoint installation, which is explained in the Tivoli Enterprise Installation Guide

Implementing Policy Scripts

The endpoint manager and gateway include the ability to use policy scripts to perform certain actions at various stages of the endpoint login process. Endpoint policy differs from default and validation policy in that policy objects are not associated with the endpoint scripts. Refer to the section about endpoint policy scripts in the Tivoli Management Framework Reference Manual for option information and instructions for editing.

The run time of these policy scripts affects the number and efficiency of logins that the gateway and the endpoint manager can process at one time. For an environment with a large number of endpoints, limit the number of commands that are placed in the policy scripts, because commands might required long periods of time and large amounts of processing resources to run. In certain cases, the endpoint can become isolated after waiting too long for the gateway to respond, which can impact endpoint manager performance.

For example, you have 1,000 endpoints logging in to a gateway at approximately 9:00 a.m. Because the run time of the policy scripts take longer to complete for each login, additional logins have to wait for the preceding logins to complete. When the preceding logins complete, the gateway and the endpoint manager are available to process additional login requests. If you need to run Tivoli commands in this context, use endpoint policy scripts to trigger tasks after login. See the section about the task library in the Tivoli Management Framework User's Guide for information about how to create tasks.

Table 2 describes the origin (where the script runs) and the trigger (when the script runs) for each endpoint policy script:
 

Table 2. When and where endpoint policy scripts run
 

Note:

For NetWare gateways, login_policy scripts are run on the gateway proxy.

allow_install_policy Policy Script

This policy script controls which endpoints are allowed to log in to the Tivoli region. For example, you might not want endpoints from subnet 26 on this Tivoli region. The default behavior of this policy allows endpoints to log in unconditionally. You can also use this policy to perform any pre-login actions you might need. For example, this policy can help filter duplicate logins to the endpoint manager when the endpoint manager is overloaded with activity or policy scripts are taking a long time to run.

The allow_install_policy script is run by the endpoint manager as soon as it receives an endpoint initial login packet from an intercepting gateway. If the policy script exits with a nonzero value, the login process is terminated immediately. If the policy exits with a zero value, the login process continues.

select_gateway_policy Policy Script

This policy script, run by the endpoint manager, provides an ordered list of gateways that should be assigned to an endpoint. The select_gateway_policy script is run each time an endpoint login packet is forwarded to the endpoint manager. The select_gateway_policy script overrides the default selection process and should be used for Tivoli environment with multiple gateways. If an endpoint is isolated, the endpoint uses the list of alternate gateways, which were provided by this policy script. This list is sent to the endpoint with the initial login assignment information and after a migration or normal login.

The endpoint manager tries to contact each gateway in the order listed in the policy script until it successfully contacts a gateway. The first gateway contacted is the gateway to which the endpoint is assigned. The intercepting gateway is also added to the end of the list in the policy script to ensure that the endpoint has at least one definite contact. If the gateways listed in the script cannot be contacted, the endpoint manager assigns the intercepting gateway to the endpoint.

after_install_policy Policy Script

This policy script is run by the endpoint manager after the endpoint has successfully been created. Because the script runs before the first normal login of an endpoint, you cannot use it to run downcalls.

The policy is run after the initial login only; it is not run on subsequent logins of an endpoint.

login_policy Policy Script

This policy script is run by the gateway and performs any action you need each time an endpoint logs in. For example, this script can be configured to automatically upgrade the endpoint software. The script is also useful for checking changes to IP addresses and port numbers. When the gateway detects changes, it notifies the endpoint manager. When the policy script exits with a nonzero value, the endpoint login will not fail.

Note:

The same login_policy policy script is run on all the gateways in a Tivoli region.

Configuration Files

An endpoint uses files to store configuration information. These configuration files reside in the dat subdirectory of the endpoint installation:

 

lcf.dat

Contains login information related to the endpoint. You cannot edit this binary file. However, certain information in this file can be overwritten by using command options when starting the endpoint service.

 

last.cfg

Contains the most recent configuration information. You configure this file with lcfd command line options. For information, see the lcfd command in the Tivoli Management Framework Reference Manual.

 

lcf.id

Contains a unique ID number to represent the endpoint. Do not copy this file from one computer system to another (for example, during mass installations), because each endpoint requires a unique identifier.

After the endpoint connects to its assigned gateway, the gateway address, port number, and any network aliases for the assigned gateway and alternate gateways are written to the lcf.dat file. All other configuration information is written to the last.cfg file. On subsequent startups, the startup commands (lcfd or lcfd.sh) read the configuration information from the lcf.dat file and the last.cfg file. As with the initial login, after the endpoint and gateway are connected, the configuration information is written to the last.cfg file.

To change the configuration of an endpoint, either edit the last.cfg file or restart the endpoint using one of the startup commands (lcfd or lcfd.sh) with the appropriate options. If you choose to edit the last.cfg file, the new configuration information is used when you restart the endpoint. When connected, the information is again written to the last.cfg file.

The lcfd Command

If you start an endpoint from the command line using either lcfd or lcfd.sh, the options you specify override the equivalent entries in the last.cfg file. The endpoint restarts with the new configuration, which is written to the last.cfg file when the connection is complete. This new configuration is used in all future startups.

The lcfd command can also be used to set the way an endpoint sends its initial login information. Specifically, the -g option of the lcfd command enables you to specify the gateway or gateways that an endpoint will try to contact. The following is an example of this parameter:

lcfd -g elm_gateway+9494:ash_gateway+9494

This example restarts the local endpoint and specifies two gateways the endpoint will try to log in to. The endpoint tries to connect to elm_gateway first and then tries ash_gateway on default port 9494.

Note:

This option does not specify the gateway to which the endpoint is ultimately assigned. Only the endpoint manager can assign a gateway to an endpoint.

Sharing Endpoint Resources across Regions

The Endpoint and EndpointManager resources can be exchanged across connected Tivoli regions. These resources can be shared to enable profile distribution and running tasks supported by the endpoint. Direct management of the endpoint (such as migrating endpoints to new gateways or listing the endpoints assigned to a gateway) must, however, be performed within the Tivoli region local to the endpoint. Management commands, such as wgateway, wep, and wdelep, must be run within the Tivoli region. For more information about these commands, refer to the Tivoli Management Framework Reference Manual.

If you share the Endpoint resource, you must also share the EndpointManager resource. The Gateway resource can also be shared, but there is little benefit in doing so. Therefore, do not share the Gateway resource. Refer to Basic Resources and Exchangeability for more information about shared resources.

Endpoint Migration

You can change the gateway assigned to an endpoint by migrating the endpoint to a new gateway. The wep migrate command prompts the endpoint manager to update both the new and old gateways. Because the endpoint might not be reachable at the time its gateway assignment is changed, the endpoint is not directly notified. When the endpoint-to-gateway communication is established, the migration is complete.

Note:

Endpoints cannot be migrated across Tivoli region boundaries.

The following processes complete the migration of an endpoint:

 

downcall

Gateways automatically receive migration information from the endpoint manager. Therefore, a downcall sent by the newly assigned gateway reaches the endpoint without a problem. The endpoint reads the new gateway address and updates its lcf.dat file. Subsequent communication is sent to the new gateway.

Note:

This process is not supported when gateways and endpoints are separated by a NAT device. NAT environments must rely on upcall and login to complete the migration process.

 

upcall

If a migrated endpoint sends an upcall, its formerly assigned gateway recognizes that it no longer manages the endpoint and intercepts the request. The intercepting gateway obtains the new gateway assignment for the endpoint from the endpoint manager. This information is forwarded to the endpoint. The endpoint then logs in to its new gateway and resends the upcall.

 

login

The treatment of a login request from a migrated endpoint to its formerly assigned gateway is similar to the upcall process. The former gateway intercepts the endpoint login request. It then obtains the new gateway assignment for the endpoint from the endpoint manager. This information is forwarded to the endpoint. The endpoint then logs in to its new gateway.

If the former gateway is unreachable, the endpoint proceeds as if isolated. The endpoint uses its list of alternate gateways (either from the endpoint manager or select_gateway_policy script) to try to log in to another gateway. If the endpoint fails to log in to any of the alternate gateways, the endpoint sends a broadcast packet (if configured). The login process is similar to the isolation login process in that the gateway selection process is triggered.

Note:

The entries in the select_gateway_policy script take precedence over the gateway specified by the wep migrate command if the endpoint is unable to contact its former gateway.

Preferred Gateways

Tivoli endpoints are automatically assigned to another gateway if they cannot contact their assigned gateways. However, an administrator can set a preferred gateway for an endpoint. When the preferred gateway of an endpoint becomes available, the endpoint can be configured to migrate back to its preferred gateway. Refer to the wep command in the Tivoli Management Framework Reference Manual for more information about setting preferred gateways.

The preferred gateway field is set to the first gateway returned by the select_gateway_policy script anytime this script is run for the endpoint. If the select_gateway_policy script does not return a list of gateways, the preferred gateway field is set to the assigned gateway during the initial login of the endpoint.

Movement of endpoints to their preferred gateways can take place in the following ways:

• An administrator sets the wep automigrate attribute to on or nonmobile. This attribute defaults to off, so there is no automatic migration unless an administrator enables this feature. Setting automigrate causes endpoints to migrate back to their preferred gateways when that gateway becomes available. Mobile endpoints are excluded from this migration if the attribute is set to nonmobile.
• An administrator uses the wep migrate_to_pref command to manually migrate endpoints to their preferred gateway. The migrate_to_pref option migrates endpoints to their preferred gateways if the preferred gateway is available. As with the wep migrate command, wep migrate_to_pref does not cause any communication with the endpoint. Only endpoint manager and gateway data are updated.

Endpoints can be excluded from automatic migration by clearing their preferred gateway attribute.

Method Storage and Implementation

A subset of Tivoli operations, called endpoint methods, run directly on the endpoint. The endpoint passes the results of these operations back to the gateway, which forwards them to the calling managed node. Other Tivoli operations run on the gateway proxy (the hosting managed node) on behalf of the endpoint. Results of these gateway methods are passed to either the endpoint or to the calling managed node.

An endpoint is not installed with any methods. Instead, the endpoint maintains a method cache. Before a method is invoked on the endpoint, the endpoint cache is checked to determine if the method is already available.

If not, the method is downloaded from the endpoint gateway and added to the cache. If the method is already in the cache, the endpoint and its gateway determine if the cache contains the most recent version of the method. If not, an updated method is downloaded. If a current version of the method exists in the endpoint cache, the endpoint runs the method and returns all results to the gateway.

The cache enables the endpoint to build up a set of methods that it can execute quickly. It also allows the endpoint to be easily updated by downloading newer methods as needed. The default maximum size of the cache is 20 MB. You can change the maximum with the lcfd (or lcfd.sh) -D cache_limit=max_size command.

Considerations for NetWare and OS/2 Gateways

Tivoli Management Framework provides standalone gateways; that is, they cannot be considered as managed nodes. These gateways are available for Novell NetWare and OS/2 operating systems. In general, they provide the same functionality of other gateways:

• Endpoint login and communication
• Invocation of methods to be run on the endpoint and gateway

Refer to the Tivoli Management Framework Release Notes for details on the functionality available for NetWare and OS/2 gateways. This section describes some of the special considerations of these gateways.

NetWare Gateways

For the Novell NetWare operating system, you need to consider the gateway proxy and IPX support.

Gateway Proxies for NetWare

NetWare gateways require a gateway proxy to run endpoint policy scripts. Any managed node can act as a gateway proxy. Using the wgateway command, you define a list of managed nodes that will act as a gateway proxy. The NetWare gateway contacts each of the managed nodes in the list, one at a time, until it finds a managed node available to run the script. If all the managed nodes in the list are down or unavailable, the NetWare gateway is unable to run the endpoint policy scripts. By default, no gateway proxies are defined. Refer to the wgateway command in the Tivoli Management Framework Reference Manual for information about modifying gateway proxies.

IPX Support

The NetWare gateway allows you to connect to endpoints with Transmission Control Protocol/Internet Protocol (TCP/IP) or IPX. To connect to an endpoint in IPX, you can use the IPX address, name resolution, or IPX broadcast. IPX/SPX name resolution allows login by the server name of the NetWare gateway. Thus, the endpoint does not have to know the IPX address of the NetWare gateway for login. It is important to note that this name resolution uses RIP packets. Refer to the Novell documentation for more information about routing RIP packets.

For endpoint logins in Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX) environments, you can explicitly specify the IPX address of the NetWare gateway where to log in. Alternatively, if the requested gateway is located within a five-hops radius from the endpoint, you can specify the gateway's server name instead of its IPX address. If you do not specify any gateway and the endpoint broadcast is enabled, the IPX login packet is sent to all the servers located within a five hop radius.

Both the IPX/SPX name resolution for the gateway and the IPX extended broadcast login make use of the Routing Information Protocol (RIP). Specific RIP routing configurations can affect their functionality. The use of IPX/SPX name resolution for the gateway and IPX extended broadcast perceptibly slows down the endpoint initial login.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019