Softpanorama

May the source be with you, but remember the KISS principle ;-)
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

Endpoint Logins

An endpoint performs four types of logins: initial, normal, isolated, and orphan. First, the initial login is performed, and then the normal login is performed.

For a normal login sequence, the endpoint logs in to its assigned gateway and the gateway acknowledges it. The initial login process is more complex. This process establishes the endpoint as an active member of its Tivoli region by assigning it to a gateway.

An endpoint is isolated when it cannot contact its assigned gateway. When that occurs, it initiates an isolated login. In certain cases, an endpoint can become orphaned when the endpoint manager no longer has an entry in its database for the endpoint. Isolated and orphan logins are discussed in Isolated Login and Orphan Login, respectively.

If the endpoint is unable to contact its assigned gateway, additional gateways are provided through a list of login interfaces or gateway addresses. This list is compiled by the endpoint manager, defined in the select_gateway_policy script, or configured with lcfd command options.

Note:
Depending on how your environment supports network address translation (NAT), you might need to define the host names for gateways in the select_gateway_policy script. The gateways defined through select_gateway_policy or the lcfd command can be host names instead of object identifiers (OIDs).

To facilitate the login process and endpoint communication, configure login parameters during endpoint creation or with the lcfd command after installation. For more information about the lcfd command and the select_gateway_policy script, refer to the Tivoli Management Framework Reference Manual.

 

Initial Login without a Select Gateway Policy

The following are the phases of the initial login process of an endpoint:

The first step in the initial login process for an endpoint is finding a gateway in the Tivoli region. The endpoint cannot be managed until it becomes associated with a gateway. The endpoint start by sending an initial login packet to a gateway, which acts as an intercepting gateway. An intercepting gateway handles communication and login for the endpoint until it has an identity and is assigned to a gateway. If no configuration options are set, either during installation or during the startup of the lcfd service, the endpoint broadcasts for a gateway. Because of network load, do not use broadcast as a means for endpoint login. Instead, use lcfd -D bcast_disable=1 to disable broadcast and use lcfd -D lcs.login_interfaces=address to specify a gateway.

Note:
If your environment supports NAT devices that share IP address assignments through dynamic timeslicing, ensure that the IP address assignment timeout value is greater than the udp_interval setting on the endpoint.

Figure 18 illustrates the initial login process of an endpoint.

Figure 18. Initial login process of an endpoint

View figure.
 

  1. The endpoint's login request is intercepted by a gateway.
  2. The gateway forwards the login request to the endpoint manager.
  3. Having no defined policy, the endpoint manager assigns the endpoint to the intercepting gateway and sends the new login information to the gateway. The endpoint manager adds up to five alternate gateways to the endpoint's alternate gateway list. The gateway relays the information to the endpoint.
  4. The endpoint logs in to its assigned gateway.

To summarize the initial login, the following are general parameters and default timeouts:

  1. The endpoint uses a set of gateway addresses configured during installation to establish a gateway to receive the endpoint's login request.
  2. If login fails to all the addresses in the lcs.login_interfaces list, the endpoint broadcasts a request to log in (if broadcast is enabled).
  3. If no gateways in the lcs.login_interfaces list respond or the broadcast login request fails, the endpoint waits 30 minutes (the login_interval default of the lcfd command) before beginning the login process again with step 1.
  4. If the login is successful, the endpoint receives its identity in the Tivoli region from the intercepting gateway along with the name of its assigned gateway.
  5. When logged in, the endpoint performs a normal login to its assigned gateway.

 

Initial Login with a Select Gateway Policy

Defining the select_gateway_policy script provides the endpoint manager with an ordered list of gateways. The endpoint manager attempts to contact each listed gateway until it makes a valid connection. The first gateway to respond receives the endpoint assignment. For more information about endpoint policy, refer to Implementing Policy Scripts.

The endpoint manager assigns a gateway and adds the endpoint information and gateway assignment to its endpoint list. The endpoint manager establishes a unique identity for the endpoint. The endpoint information is sent back to the intercepting gateway. The intercepting gateway relays the assignment information to the endpoint. The endpoint performs a normal login to its assigned gateway.

Figure 19 illustrates the endpoint's initial login process, where a select_gateway_policy script has been defined listing two gateway options. The endpoint manager tries to contact the gateways in the order listed in select_gateway_policy. In this example, gateway A is listed first and gateway B is listed second. Gateway B is the first to respond to the endpoint manager.

Figure 19. Endpoint initial login with select_gateway_policy defined

View figure.
 

  1. The endpoint login request is intercepted by a gateway.
  2. The gateway forwards the login request to the endpoint manager.
  3. The endpoint manager refers to the select_gateway_policy script and attempts to contact gateway A and then gateway B.
    1. Connection with gateway A fails.
    2. Contact with gateway B is successful. Gateway B becomes the endpoint's assigned gateway. Gateway A and gateway B are added to the lcs.login_interfaces list.
  4. The endpoint manager returns the login assignment information to the intercepting gateway. The intercepting gateway then relays the information to the endpoint.
  5. The endpoint logs in to its assigned gateway.

In Figure 20, an interconnected Tivoli region was created to redirect endpoint initial logins to their endpoint manager on the Tivoli server in the local Tivoli region. This scenario can be common in large, multisite enterprises where thousands of endpoints are logging in to multiple regions. A Tivoli region dedicated to redirecting endpoint logins can ensure that endpoints log in to gateways in their local region. Tivoli server A is the redirecting Tivoli region and has the select_gateway_policy script defined. Gateway A is local to Tivoli server B and is listed in the select_gateway_policy script.

Note:
Endpoints must be managed in their local Tivoli region.

Figure 20. Endpoint redirection to another Tivoli region

View figure.
 

  1. The endpoint login request is intercepted by a gateway.
  2. The gateway forwards the login request to the endpoint manager.
  3. The endpoint manager refers to the select_gateway_policy script and finds gateway A in Tivoli region B first on the list. The endpoint manager retrieves gateway A's interface information.
  4. The endpoint manager sends the network interface information of gateway A with directions to use it as the intercepting gateway to the original intercepting gateway. The gateway relays the information to the endpoint.
  5. The endpoint begins the initial login process again with the new information. The login request is intercepted by gateway A, as designated in the policy script in region A. Gateway A is acting as an intercepting gateway.
  6. The request is forwarded to the endpoint manager in region B.
  7. Having no defined policy in region B, the endpoint manager assigns the endpoint to gateway A and sends the new login information to the gateway. The gateway relays the information to the endpoint.
  8. The endpoint logs in to its assigned gateway.

 

Normal Login

After an endpoint is established as a member of its Tivoli region through the initial login process, subsequent or normal logins occur. During a normal login, communication takes place between the endpoint and gateway only. The endpoint sends a login packet directly to its assigned gateway stored in the lcf.dat file. See Figure 21 for an illustration of normal login.

Because the gateway has the endpoint in its endpoint list, communication is established immediately without contacting the Tivoli server or the endpoint manager. The endpoint then performs the following operations:

Figure 21 illustrates the flow of data for logins after the first login. A normal login occurs when the endpoint service starts. After the normal login is successful, each communication to or from the endpoint is done as an upcall or downcall with the exception of an isolated login.

Figure 21. Endpoint normal login

  1. The endpoint logs in to the assigned gateway. The endpoint is immediately established as a communicating member of the Tivoli network.
  2. The endpoint manager is not contacted.

To summarize the normal login, the following are the general parameters and default timeouts:

  1. Using the gateway list, which is given to the gateway by the endpoint manager, the endpoint attempts to contact its assigned gateway. If this fails, the endpoint attempts to contact any aliases of the assigned gateway. The attempts are specified by the udp_attempts option. The time between each attempt is specified by the udp_interval option.
  2. When the endpoint cannot contact its assigned gateway or aliases, the endpoint enters isolation mode and uses a set of gateway addresses (configured during installation) to contact a gateway to receive the endpoint login request:
    • These gateway addresses are specified by the lcs.login_interfaces option.
    • By default, the endpoint attempts to contact each of the gateways six times with 5 minutes between each attempt. The attempts are specified by the udp_attempts option. The time between each attempt is specified by the udp_interval option.
    • If the endpoint is successful in contacting one of the alternate gateways, endpoint policy scripts run.
  3. If login fails for all the addresses in the lcs.login_interfaces list, the endpoint broadcasts a request to log in (if broadcast is enabled).
  4. If no gateways in the lcs.login_interfaces list respond or the broadcast login request fails, the endpoint waits 30 minutes (the login_interval default of the lcfd command) before beginning the login process again with step 1.

Isolated Login

When an endpoint cannot contact its assigned gateway, the endpoint is considered isolated. The following are some examples of how an endpoint can become isolated:

For the endpoint to be assigned quickly to a new gateway, each endpoint receives a list of alternate gateways when it receives its initial gateway assignment information. The list of alternate gateways can be defined in and provided by the select_gateway_policy script. If the select_gateway_policy script is not defined, the endpoint manager sends a list of up to five gateway addresses to try.

If the endpoint loses contact with its assigned gateway, the endpoint goes through a list of alternate gateways (and associated aliases) in its attempts to log in. If the endpoint fails to log in to any of the alternate gateways, the endpoint sends another isolated login packet. The login process is similar to the initial login process described in Initial Login without a Select Gateway Policy in that the gateway selection process is triggered. Also, the lcs.login_interfaces list is replaced with a new list of gateways, instead of appended with new gateways (as in the initial login).

To summarize the isolated login, the following are the general parameters and default timeouts:

  1. When the endpoint cannot reach its assigned gateway, the endpoint uses a set of gateway addresses configured during installation to contact a gateway to receive the endpoint login request.
  2. If login fails for all the addresses in the lcs.login_interfaces list, the endpoint broadcasts a request to log in (if broadcast is enabled).
  3. If no gateways in the lcs.login_interfaces list respond or the broadcast login request fails, the endpoint waits 30 minutes (the login_interval default of the lcfd command) before attempting to contact its assigned gateway again.

Orphan Login

An endpoint is an orphan when the endpoint considers itself a member of a Tivoli region; however, the endpoint manager and Tivoli name registry do not recognize that the endpoint ever logged in. Thus, you will not be able to perform any actions on those endpoints, such as software distributions or inventory scans, until it rejoins the Tivoli region. Endpoints can become orphaned in the following cases:

The first case occurs when you have to restore the Tivoli server from a backup. In most cases, backups are done on a regularly scheduled basis. After one of these backups, it is likely that new endpoints will log in to the region for the first time. These new endpoints, therefore, are recorded in the endpoint manager, but do not appear in the backup until the next scheduled backup occurs. When the database is restored from the backup, the new endpoints are no longer represented in the endpoint manager. The endpoints, however, still have the endpoint service running.

The second case occurs when the wdelep command is run inadvertently, and the endpoint service is not stopped and removed from the endpoint. Because the endpoint service runs independently from the endpoint manager, the endpoint does not know that the endpoint manager no longer knows about the endpoint. Thus, the endpoint still considers itself part of the region. Until the endpoint attempts an action that affects the endpoint manager, such as an upcall, the endpoint will not know it is an orphan. If the endpoint attempts to log in to its assigned gateway, it fails and enters isolation mode.

You can also use allow_install_policy and select_gateway_policy scripts to control how orphan endpoints are added back to the endpoint manager database. For security of individual regions, the endpoint cannot be redirected to another Tivoli region from its original one during the orphan login. Also, the lcs.login_interfaces list is replaced with a new list of gateways (as in the isolated login), instead of appended with new gateways (as in the initial login).

To summarize the orphan login, the following are the general parameters and default timeouts:

  1. When the endpoint cannot reach its assigned gateway, the endpoint uses a set of gateway addresses configured during installation to contact a gateway to receive the endpoint login request:
  2. If login fails for all the addresses in the lcs.login_interfaces list, the endpoint broadcasts a request to log in (if broadcast is enabled).
  3. If no gateways in the lcs.login_interfaces list respond or the broadcast login request fails, the endpoint waits 30 minutes (the login_interval default of the lcfd command) before attempting to contact its assigned gateway again.



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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard 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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting 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-MonthHow 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

Disclaimer:

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