||Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix|
You can configure an endpoint in the following ways:
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
||Run by the endpoint manager||Run when the endpoint installation begins|
||Run by the endpoint manager||Run each time an endpoint needs to be assigned to a gateway|
||Run by the endpoint manager||Run directly following the endpoint installation and initial login|
||Run by the gateway||Run each time the endpoint logs in|
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.
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.
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.
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.
An endpoint uses files to store configuration information. These configuration files reside in the dat subdirectory of the endpoint installation:
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.
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.
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.
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.
The following processes complete the migration of an endpoint:
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.
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:
Endpoints can be excluded from automatic migration by clearing their preferred gateway attribute.
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.
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:
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.
For the Novell NetWare operating system, you need to consider the gateway proxy and IPX support.
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.
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.
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
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
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
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
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
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to to buy a cup of coffee for authors of this site|
Last modified: March 12, 2019