Troubleshooting endpoints

Endpoint problems represent the primary causes of failures within a Tivoli environment.  See also

• Endpoints
• Tivoli lcdf daemon

There three major types of endpoint problems:

• Malfunctioning endpoints are endpoints that appear to be active endpoints, but do not perform as expected. They are unable to receive distributions or to function as a normal endpoint. For Server machines that should always be available, this indicates a problem with the endpoint that may be due to unexpected network or operating system changes. For Desktop machines, the projected availability has an affect on whether the endpoint is ‘really’ malfunctioning or not. Particularly considering that the machine may be turned off and distributions to it would fail (of course this depends on the distribution settings, etc.). Determining malfunctioning endpoints is difficult until an action is attempted on them.
   

• Login problems are endpoints that are performing persistent logins. Often this is connected with the fact that the name of gateway cannot be resolved via DNS and not encoded in the /etc/hosts file.  First you need to verify if the dame of gateway is resovable via DNS and add it, if nessesary to the /etc/hosts file. if this does not help try modifying the value of the keyword lcs.login_interfaces in last.cfg  to:

  lcs.login_interfaces=TMA_server_ip+9494

  In general, an endpoint should not attempt to login often unless a gateway failed or it was migrated to another gateway. It is important to track endpoint logins because these endpoints may not be manageable through Tivoli, and extraneous logins can cause performance problems with the Gateways and Endpoint Manager.
  
  Unlike malfunctioning endpoints, these endpoints can be proactively resolved by monitoring the typical Tivoli log files (epmgrlog, gatelog).
   

• Old endpoints are inevitable in any Tivoli environment and must be dealt with because attempts will be made to manage endpoints that do not exist. This causes perceived failures that require time to resolve and reflect poorly on management statistics. Old endpoints are caused by removing a physical machine or endpoint without it being removed from the Tivoli Environment.
   

• A policy must be put in place that defines an old endpoint and how it should be handled.

Tips:

• Script  /opt/Tivoli/lcf/dat/1/lcf_env.sh is identical to the start up script /etc/init.d/Tivoli_lcfd1
   
• The key for the success of troubleshooting is having baseline and having a similar endpoint connected to the same gateway.
   
  • Diff the last.cgf files form successfully connected endpoint and a failed one. The only difference usually is the line:

    lcs.machine_name=endpoint-name,

    for example: “lcs.machine_name=cat630-ep” or lcs.machine_name=server06_ep

    (If you are renaming a system, this line needs to be changed.) See Installing endpoints through an existing Tivoli environment
     

• Always source system variables from /opt/Tivoli/lcf/dat/ep_dir/lcf_env.sh before troubleshooting. For example

  . /opt/tivoli/lcf/dat/1/lcf_env.sh

  The most useful variable is $LCF_DATDIR which puts you into data directory on this endpoint instance.

• Other things equal it's better to have 4.1.1-LCF-0058 patch applied.  That might save you some time.
   
• If the problem is common across different platforms it might be a gateway problem.
   
• You can run endpoint with the debug level three to see details of endpoint communication with the gateway.   To increase the debug level on the 'LCFD.LOG ' to ' 3 ' you can use one of the following methods:
  • Change the value of the 'log_threshold=' line in the 'last.cfg' from ' 1 ' to ' 3 '
  • Use the 'lcfd -d <level>' command e.g. 'lcfd -d 3'
  • Use 'wep set_config' - on later versions this is activated without having to restart the Endpoint. On previous versions, you have to restart the Endpoint to get the new debug level recognized.
     
• You you have found problem with communicating to gateway try adding the following line to the end of the 'last.cfg' file in the 'C:\Program Files\Tivoli\lcf\dat\1' directory:

  lcs.login_interfaces=<Gateway_IP_address>+<port_number>

  Save the file and then restart lcfd daemon. See IBM - Correct usage of lcs.gateway_address parameter of lcfd.

• Use lcfd.sh stop && lcfd.sh start -- to reload endpoint
• Use wgateway <gateway_name> stop && wgateway <gateway_name> start -- restart gateway
• Use http://endpoint_DNS_name/:9495 -- Using HTTP to get status of the endpoint

Troubleshooting steps to consider:

Step 1: Check connectivity to gateway. From the Tivoli server run the ping command from to confirm that the endpoint is accessible over the network. If you receive connection or timeout errors, stop at this point and contact your network administrator for help.

• Check with “telnet IP-address port”, for example “telnet 10.201.147.30 9495”. If it connects and then closes the connection, it is communicating.

Step 1: Determine status of the particular endpoint using wepstatus  command

wepstatus sun240-ep

Step 2: Analyze lcfd.log. Check connectivity to the gateway (should be both ways, DNS resolution, etc).

Step 3: Attempt to restart endpoint with debug level 3. If it fails it might produce useful information about the failure.

For more information see

Endpoint adapter troubleshooting

1. Use the wep ls command to make sure that the endpoint is shown under the Tivoli Management Framework gateway you want. See the IBM Tivoli Enterprise Console Command and Task Reference for more information. Also make sure that any Tivoli Management Framework gateway the endpoint can log on to has the Adapter Configuration Facility installed.
2. Source the endpoint environment and edit the last.cfg file in $LCF_DATDIR. Set log_threshold to 3 and then stop and restart the endpoint to enable endpoint tracing to the lcfd.log file. Check to make sure that the endpoint logged into an appropriate Tivoli Management Framework gateway.
3. If the endpoint has logged into a Tivoli Management Framework gateway successfully, create and distribute the adapter configuration profile (see the IBM Tivoli Enterprise Console User's Guide for details). Check the lcfd.log file if there are further problems; you can also turn on tracing at the Tivoli Management Framework gateway and look in $DBDIR/gatelog for further debugging information.
4. If events do not arrive at the event server but are not incorrectly parsed, check to see if the events are caching on the endpoint instead. If so, either the lcfd process cannot communicate to the Tivoli Management Framework gateway or the event server, or the lcfd process itself is down. Verify that all communications among the event server, Tivoli Management Framework gateway, and endpoint are working.
5. Source the endpoint environment, then use the endpoint wpostemsg command from the system the adapter is running on to see if the event arrives at the event server. See the IBM Tivoli Enterprise Console Command and Task Reference for more information.

Maintenance and Troubleshooting Guide / Troubleshooting endpoints

3.6 Tivoli Endpoint

3.6.1 Endpoint status

3.6.2 Monitoring endpoints

3.6.3 Monitoring the endpoint engine

3.6.4 Rebuilding endpoints

3.6.5 Endpoint migration, isolation, and orphaned

3.6.6 Endpoint migration scripts

3.6.7 Subscribing Endpoints to Profile Managers

3.6.8 Duplicate Endpoints

3.7 Cross-TMR endpoint migration

3.7.1 Considerations

3.7.2 Procedure

Key commands

wep

• wep ls -- list endpoints. Mostly useless. It's better to use wepstatus -a

  wep help

  wep [help [subcommand]] Get general or subcommand help messages
  wep ls [-i <info>][-d <del>][-g <gw_label>] Lists endpoints, for example

  wep ls -i all

  wep sync_gateways Sync gateways with the Endpoint Manager
  wep <label> Show ep info for endpoint named <label>
  wep <label> set field value Sets endpoint data
  wep <label> get <info> [-d <del>] Displays endpoint data
  wep <label> migrate [-f] <gw_label> Migrate endpoint to gateway
  wep migrate_to_pref [-f] {-d|-a|-n} [-m <max>] [-g <gw_label>]
  Migrate endpoints to their preferred gateways

  Advanced Commands:

  wep boot_method add <tag> <prototype_object> <method_name> <endpoint_object...>
  wep boot_method list <tag> <endpoint_object>
  wep boot_method remove <tag> <endpoint_object...>
  wep boot_method test <tag> <endpoint_object>

  wep del <ep_oid> <gw_label> Low level delete CAREFUL!
  wep view <ep_oid> <gw_label> Low level display ep info

  Rescue Commands: (These commands contact the endpoint)

  wep <label> status
  wep set gateway {-g <gw_label> | -e <ep_label>}
  wep set interfaces {-g <gw_label> | -e <ep_label>} interfaces
  wep <label> set_label [-s] <new_label> Changes the label of an endpoint
  wep <label> set_config field=value Changes endpoint configuration parameter

weptatus command

1. wepstatus -a -- list health conditions and name of the gateway and endpoints (connected/unreachable)

   syntax: wepstatus [-o file] [-f format] [-v] {endpoint_name | -a | -g gateway_name | -i file [endpoint_name...]}

   The following example returns the status for the endpoint quartz:

   wepstatus quartz

   The following example returns the status for all endpoints associated with gateway ntgw:

   wepstatus -g ntgw

Directories Structure

Tivoli endpoints like Tivoli Framework itself have complex, very convoluted directory structure with path to some some components so deeply nested in a maze of directories that this depth of nesting itself defies any developer logic and might suggest problems with architectural thinking within IBM. The good thing is that at least it is similar for all operating systems be it NetWare, OS/2, UNIX, or Windows.

The main endpoint directory structure (there is also supplementary /etc/Tivoli directory structure) contains two important subtrees:

• one leading to cache directory where all downloaded from the gateway executables reside
• second leading to mrt directory where the platform specific lcfd binary resides

Tivoli/lcf/dat/ep_dir

ep_dir is just the endpoint number, typically 1, as there is usually only one endpoint installed on the server, but it can be more if there are several independent TMF servers in the environment and each has endpoint installed on particular machine. For example on Solaris the directory is /opt/tivoli/lcf/dat/1 and it contains the following files and directories (directories are in green)

cache last.cfg lcf.id lcf_env.sh lcfd.pid lcfd.st
codeset lcf.dat lcf_env.csh lcfd.log lcfd.sh

Among important endpoint working directory subdirectories and files:

• cache Directory for downloaded binaries and files used by the endpoint to execute TMF operations. This is a real cache: binaries and files are downloaded from the gateway as needed.
• last.cfg Text file with keyword/value pairs that contains the latest configuration information used to start the endpoint. Can be editied manually or using wep command.
• lcf.dat Binary file that contains login information. Contains Management Gateway IP and port number.
  
• lcfd.log This is the most important troubleshooting file, the file that contains log messages generated by the endpoint. The name of this file actually can be different as it can be changed in the last.cfg file
  
• lcfd.sh File that contains the script file for starting the endpoint. (UNIX only)
  
• lcfd.st File that contains the status of the endpoint.

Tivoli/lcf/bin/interpr/bin

What is called interpr is actually not interpreter but the name of platform on which endpoint is deployed. For example for Solaris directory is be named Solaris2 and that full path is: /opt/tivoli/lcf/bin/solaris2/bin .

The directory contains the platform-specific binaries for the following utilities:

• postemsg
• postzmsg
• wpostemsg
• wpostzmsg
• wstoptecgw

Tivoli/lcf/bin/interpr/mrt

Contains platform specific lcfd binary used to manage endpoint.

The following system startup files are added or modified during the installation of a UNIX endpoint.

System variables

System variables

The following system variables can be set after you install an endpoint.

To use these system variables, you must run the environment setup scripts for the endpoint from either of the two scripts created during the installation:

• /opt/Tivoli/lcf/ep_dir/lcf_env.csh
• /opt/Tivoli/lcf/ep_dir/lcf_env.sh

You can change your login initialization procedure to use the appropriate setup file so that the necessary environment variables and search paths are set to allow you to start the endpoint.

For example, for Bourne or Korn shell (sh or ksh) you can add the following to your profile:

if [ -f /opt/Tivoli/lcf/1/lcf_env.sh ]; then
   . /opt/Tivoli/lcf/1/lcf_env.sh
fi

For Windows the installation process creates the following setup scripts:

• %SystemRoot%\Tivoli\lcf\ep_dir\lcf_env.cmd
• %SystemRoot%\Tivoli\lcf\ep_dir\lcf_env.sh

TMA Login Process

By default TMA will automatically attempt the initial login to a Management Gateway as soon as lcdf process is launched on newly installed endpoint. This is done by UDP broadcast using port 9494. All gateways that receive this broadcast forward the request to Tivoli Server Endpoint Manager. The gateway whose request reaches server first handles the communication during login process. Endpoint manager executes endpoint policies:

• allow install policy
• select gateway policy
• alter install policy

Assignment information is passed to TMA which stores it in LCF.DAT file. After this point all TMA communications go through the assigned Management Gateway.

After the initial login, the TMA connects directly to its assigned management gateway for subsequent logins. Only if Management gateway does not respond TMA repeats UDP broadcast to find a new gateway, if any.

Ports

By default TMA listens on port 9495, the Tivoli Gateway uses 9494

NEWS CONTENTS

• 20100422 : IBM - FRWOG0047E IPC shutdown error on wep status ( IBM - FRWOG0047E IPC shutdown error on wep status, Apr 22, 2010 )
• 20090707 : LAST.CFG PARAMETERS ( LAST.CFG PARAMETERS, Jul 7, 2009 )
• 20090707 : developerWorks Tivoli Tivoli TME10 Mailing List WindowsXP pro endpoint fails to login - ... ( developerWorks Tivoli Tivoli TME10 Mailing List WindowsXP pro endpoint fails to login - ..., )

Old News ;-)

[Apr 22, 2010] IBM - FRWOG0047E IPC shutdown error on wep status

To troubleshoot "duplicate label exists in ep_mgr" you need to delete the endpoint with wdelep

FRWOG0047E IPC shutdown error on wep status

Technote (troubleshooting)

Problem(Abstract)
Doing "wep <EP> status" gets:

The remote client was not created. ipc_create_new_remote_client failed: unable to connect to 9.19.199.199+9495: (67) FRWOG0047E IPC shutdown. ; Endpoint may not be running

Cause

The (67) on the message denotes a communications error despite the fact the endpoint is up. In the gatelog we see this in more detail with "ipc_create_new_remote_client failed: unable to connect to 9.19.199.199+9495: (67) FRWOG0047E IPC shutdown.". In the epmgrlog and the gatelog there are duplicate label errors.
What happened is a firewall has blocked the gateway from connecting to the listening port 9495 of the endpoint. The firewall only seems to be blocking the one direction. This causes a partial login which then creates a second problem: duplicate endpoint error.

Here are the logs:

epmgrlog:
-----------------------------
2006/07/05 16:27:03 4 225a6548: login: od=0 INITIAL addr=9.19.199.199+9495 label=bubba gw=1681776824.1.587
2006/07/05 16:27:03 1 225a6548: exception for login:
Terminating login from 9.19.199.199+9495 (bubba): duplicate label exists in ep_mgr.
...
2006/07/05 16:32:48 4 225a6548: login: od=0 INITIAL addr=9.19.199.199+9495 label=bubba gw=1681776824.1.587
2006/07/05 16:32:48 1 225a6548: exception for login:
Terminating login from 9.19.199.199+9495 (bubba): duplicate label exists in ep_mgr.
-----------------------------

gatelog (at debug level 6):
-----------------------------
2006/07/05 16:27:03 3 300a6518: reconnect: from addr=9.19.199.199+1025
2006/07/05 16:27:03 3 300a6518: tcp_server: listening on 0.0.0.0+9494
2006/07/05 16:27:03 3 300a68f8: reader: call ipc_timed_recv: timeout=300
2006/07/05 16:27:03 3 300a68f8: reader: type=login od=0 addr=9.19.199.199+1025 len=434: send_timeout=310
2006/07/05 16:27:03 5 300fefc8: eplogin:START: od=0 addr=9.19.199.199+1025 unwrapped login_info, type=INITIAL
2006/07/05 16:27:03 5 300fefc8: login_filter: od=0 cur(status=0 ver=41022) old(status=0 ver=41022)
2006/07/05 16:27:03 5 300fefc8: login_initial: from od=0 addr=9.19.199.199+1025: label=bubba interp=w32-ix86 id=d634786011db8026e8f6a3105304
2006/07/05 16:27:03 1 300fefc8: login_initial: od=0 addr=9.19.199.199+1025 label=bubba interp=w32-ix86: exception msg:
Terminating login from 9.19.199.199+9495 (bubba): duplicate label exists in ep_mgr.
2006/07/05 16:27:03 5 300fefc8: od=0 addr=9.19.199.199+1025: send_login_results
...
2006/07/05 16:28:18 2 300fefc8: send_login_results: od=0 addr=9.19.199.199+1025: packet_type=15: exception msg=
The remote client was not created.
ipc_create_new_remote_client failed: unable to connect to 9.19.199.199+9495: (67) FRWOG0047E IPC shutdown.
2006/07/05 16:28:18 5 300fefc8: eplogin: END: od=0 addr=9.19.199.199+1025
-----------------------------

So, why are we getting duplicate endpoint labels?: As you can see from the logs the od=0 is listed and type=INITIAL. Both of those mean this is the endpoints first time logging in. Yet since the instance exists in the TMR. So, this endpoint started to log in at one time, were created in the epmgr db, thus given and OD# but that login process then broke when it tried to send the OD# to the endpoint. So the endpoint then does not know its OD# and then when attempting to log in it is viewed as a duplicate.

Resolving the problem
1) Open what ever is blocking the gateway from reaching the endpoint's port 9495. Firewall or personal firewall is blocking port 9495.
2) wdelep the endpoint from the TMR, so that the partially logged in EP can now log in. Otherwise it will get rejected as a duplicate.

[Jul 7, 2009] LAST.CFG PARAMETERS

lcfd_port=9495 Identifies the port on which the endpoint daemon (lcfd) monitors gateway communications. The default value is 9494. This option can also be set using lcfd -P.

lcfd_preferred_port=9495 To define the preferred port

fail_if_pref_port_busy=0 Controls portmapper walking. Default = 0 Under firewall configuration, if lcfd process should not use random port other than specified in preferred or alternate port, then specifying this parameter. Setting this parameter tells lcfd process to terminate if either preferred or alternate port is not possible to acquire or in other words it is busy (fail_if_pref_port_busy=1)

gateway_port=9494 Identifies the port on which the gateway monitors endpoint communications. The default value is 9494. This option can also be set using lcfd -p.

bcast_disable=0 Disables the UDP broadcast when set to 1. If you set this option to 1, you must use the lcs.login_interfaces option. default is 0

http_disable=0 The default setting for the endpoint http is controlled by the configuration key 'http_disable'. At default installation, the value of http_disable=0.

0 - default, grants full access to endpoint http Operations services.

1 - grants access to endpoint http Operations service but denies access to 'Additional configuration options'

2 - grants access to 'TMA Daeman Status Page' but denies all Operations access.

3 - grants full access to endpoint http Operations only after authentication through User/Password popup.

log_threshold=3 Identifies the level of debug logging.Messages are written to the lcfd.log file. The following are valid entries:

0 No message logging

1 Minimal logging (default)

2 Tracing and moderate output

3 Detailed information and tight loops

4 Data

start_timeout=120 Specifies the wait time (in seconds) before a communication timeout occurs during login. This parameter gets used after the login process has started (default = 120) When an endpoint in the established state is started, it sends a TCP login packet to its primary gateway and waits for start_timeout seconds for a response before doing anything else.

run_timeout=120 Specifies the wait time (in seconds) before a communication timeout occurs following a successful login. (Default = 120) Once an endpoint is logged in and running, if it needs to send an upcall, it attempts to contact its gateway via a TCP packet, and waits for run_timeout seconds for a response before doing anything else.

lcfd_version=106 Identifies the current running framework code lcfd version

logfile=C:\Program Files\Tivoli\lcf\dat\1\lcfd.log Identifies the absolute path to the file in which status messages are logged. The default log file is lcfd.log. Editing this option is not recommended.

config_path=C:\Program Files\Tivoli\lcf\dat\1\last.cfg Identifies the absolute path to the LAST.CFG configuration file. Editing this option is not recommended.

run_dir=C:\Program Files\Tivoli\lcf\dat\1 Identifies the directory from which the endpoint daemon will run. Specifies also the name of the endpoint's current working directory. This directory contains configuration files needed for startup and the method cache.Editing this option is not recommended.

load_dir=C:\Program Files\Tivoli\lcf\bin\w32-ix86\mrt

lib_dir=C:\Program Files\Tivoli\lcf\bin\w32-ix86\mrt Specifies the path to the configuration library, which contains the shared libraries required by an endpoint. This argument does not apply to NetWare.

cache_loc=C:\Program Files\Tivoli\lcf\dat\1\cache Identifies or changes the name of the method cache created and maintained on the endpoint. This argument can also be used to change the location of the method cache when submitted with a full path name.

cache_index=C:\Program Files\Tivoli\lcf\dat\1\cache\Index.v5

cache_limit=20480000 Specifies the maximum size of the method cache. Once this maximum size is reached, the least recently used methods are deleted to make room for current methods.

debug_flags=debug_level Enables the user to attach a debug tool to a running method. Editing this option is not recommended.

log_queue_size=1024 Specifies the maximum amount of memory (measured in bytes) used for the log queue. Only LogQ messages are sent to the log queue. If an exception occurs, the entire queue is printed to the screen. Valid range is 1024 through 102400.

log_size=1024000 Specifies the maximum size (in bytes) of the log file. Valid range is 10240 through 10240000.

udp_interval=300 Specifies the number of seconds between endpoint initial login request attempts It defines the amount of time between an initial login broadcast if the login fails (default: 300 seconds) When an established endpoint is attempting solation logins, or an initial endpoint is trying an initial login, it sends a UDP packet to a gateway and waits for udp_interval seconds for a response before doing anything else.

udp_attempts=6 Specifies the number of times an endpoint will transmit an initial login request.(default: six times) If an endpoint is isolated, or is trying to login for the first time, it will try to send a UDP packet udp_attempts times before trying the next gateway in its list.

address_notif_interval=0 The endpoint will send a packet containing its ip address to its gateway every address_notif_interval seconds. This interval is designed so DHCP endpoints whose ip address changes after a successful login, can eventually be contacted again by the gateway. The default value for this parameter is 0. When this parameter is set to a number of seconds (in the last.cfg), then the Endpoint at that interval will perform an upcall in order to periodically notify the Gateway of its current IP address.

login_interval=1800 Specifies the waiting period before an endpoint executes another login attempt. The default is 1800 seconds (30 minutes). When an endpoint has exhausted all of its gateways trying any kind of login, it waits in a listening state for login_interval seconds before beginning the cycle again.

lcs.machine_name=hostname Identifies the endpoint label as shown in wlookup or wep. You can also use the -n option to identify an endpoint label.

lcs.machine_unique_id= Identifies the unique identification of the endpoint.

lcs.crypt_mode=196608 Determines the encryption mode of an endpoint A value of 196608 means the encryption level is NONE A value of 196610 means the encryption level is DES

lcs.crypt_key_len=0

lcs.interp=w32-ix86 Identifies the interpreter type of the endpoint. Editing this option is not recommended.

lcs.login_interfaces= <gatewayIP>+<port> Specifies the IP address or hostname and port number of one or more gateways to which an endpoint will send its login packet. This option is required for the endpoint to log in to a gateway on a different subnet or to log in to a specific gateway when two or more exist on a subnet. If your gateways and endpoints are separated by a network address translation (NAT) device, specify hostnames instead of IP addresses. Multiple addresses must be colon separated. You can also use the -g option to list one or more gateways.

lcs.gateway_address= Changes the login gateway after the endpoint has successfully logged in. If the gateway has not previously logged in, use the lcs.login_interfaces option to provide one or more gateways through which the endpoint may log in.

local_ip_interface=0.0.0.0 Sets the listening address. This parameter specifies the IP address through which the endpoint should communicate with the TMR

start_delay=15 The start_delay parameter delays the startup of the endpoint service (default = 15 seconds). Value is specified in seconds.

recvDataTimeout= How many seconds to wait for data on the incoming connection before requeuing the connection (Default = 2) The recvDataTimeout parameter instructs the TMA to wait a specified number of seconds on that new connection for incoming data. If no data is received, the TMA will stop waiting on that connection and go on to another connection, if one is available.

recvDataNumAttempts= How many times to attempt to receive data on this connection before closing the connection (Default = 10)

recvDataQMaxNum= How many connections to hold in the pending connection queue at one time (Default = 50)

allow_proxy_upcalls= Default=false By setting the parameter to TRUE, the upcall method will transfer the upcall data to the lcfd through the network and will not create an upcall data file. If an endpoint is set to allow_proxy_upcalls=TRUE, the endpoint must establish a connection to a proxy capable gateway before it can request proxy upcalls.

diag_accts=false allows users to specify if the tmersrvd account and the Tivoli_Admin_Privileges group on endpoints should be checked as part of standard endpoint health checks.Default value = TRUE

use_token_pool=false With "use_token_pool=false" the lcfd.log will contain new "InitTAPCache called" and "InitTAPCache cache status is 'disabled'"entries. Each downcall should log the fact that a token was generated. With "use_token_pool=true", the second message will change to "InitTAPCache cache status is 'enabled'". Downcalls should no longer generate a new token for each invocation. "use_token_pool=false" (the default value)

filefree_upcalls= This option can be turned on and off by setting the filefree_upcalls parameter to TRUE or FALSE using wep or lcfd commands. The default value at startup is FALSE. By setting the parameter to FALSE the upcall method writes the upcall data to a disk file before it contacts the lcfd with an upcall request. The file is created in the $LCF_DATDIR/updata directory. Each upcall creates a unique DATAXXXX file there which is deleted after upcall completion. By setting the parameter to TRUE, the upcall method will transfer the upcall data to the lcfd through the network and will not create an upcall data file.

address_notif_retry_count= (controls the number of retries that are made when the lcfd attempts to send its current IP address to the gateway / the default value is 0)

auto_set_firewall=true allows the endpoint to receive incoming connections when the Windows Firewall is "Off" or "On" as long as "Don't allow exceptions" is not checked in the firewall control panel and the source of the connection is allowed by firewall_scope (if specified). The use of auto_set_firewall does not affect the endpoint method (i.e., upcall / downcall) functionality. Therefore, additional procedures, such as using TFST or setting allow_proxy_upcalls=true, may be required. [boolean]: Enable or disable firewall interaction. This parameter is enabled [true] by default.

firewall_scope [string]: Specify the preferred scope of firewall exception. This parameter is NULL by default, which allows all incoming connections. Other options include "LocalSubnet" and valid IPaddr/mask values, such as "9.41.23.0/255.255.255.0" (without the quotes). If auto_set_firewall is not enabled [true], the firewall_scope parameter is ignored.

These two endpoint parameters are provided to control this new behavior, which is only functional on Windows XP SP2 or Server 2003 SP1 (or newer) systems. (These parameters are defined but ignored for other platforms.)

login_timeout=300 Specifies the number of seconds that an endpoint waits for a response to a directed login attempt. A directed login attempt is an attempt to log in to either the last known gateway or to a gateway in the login interfaces list. The default value is 300 seconds (5 minutes).

login_attempts=3 The number of directed login attempts on a gateway before the endpoint moves to the next gateway in the list. A directed login attempt is an attempt to log in to either the last known gateway or to a gateway in the login interfaces list. The default is 3.

detect_address_delay=30 The detect_address_delay parameter is provided to control how long to wait before queueing the address notification message. LCFD process uses NotifyAddrChange windows API to detect and notify address change. The NotifyAddrChange API can signal multiple events (disable current interface, change address, enable new interface, etc.) in response to a single configuration change. Trying to send a message to the gateway too soon could result in a false failure. So this parameter is provided to control "detect_address_change" option.

detect_address_change=FALSE Specifies whether the endpoint detects changes to its network interface configuration and, if necessary, takes corrective action. When this option is set to TRUE, the endpoint monitors its network interface configuration for address changes. If the listening address for the endpoint changes, the endpoint attempts to log back in to its gateway. This option applies to Windows 2000, Windows XP, and Windows Server 2003 systems only. Default=FALSE

upcall_pool_size=100 Specifies a maximum for the number of connections in the proxy upcall pool. When the number of connections in the proxy upcall pool reaches and exceeds this value, the older connections in queue are gracefully aborted to make room for newer proxy upcall connections. The default value for the upcall_pool_size is 100. This value is reset to the default value if the upcall_pool_size is set to 0 or less than zero. The upcall_pool_size should not be set to be greater than the maximum number of file descriptors specified by the 'ulimit -a' (on UNIX platforms). The upcall_pool_size should be a low value rather than a large value.

upcall_pool_timeout=300 Specifies the maximum number of seconds that a proxy upcall connection can reside in the pool until it is gracefully aborted to make room for newer proxy upcall connections. The default value for upcall_pool_timeout is 60. This value is reset to the default value if the upcall_pool_timeout is set less than or equal to the value of the recvDataTimeout.

developerWorks Tivoli Tivoli TME10 Mailing List WindowsXP pro endpoint fails to login - ...

WindowsXP pro endpoint fails to login - Urgent Help! Posted: Aug 19, 2005 04:11:48 AM Reply Hi, FW 4.1.1- ITM 5.1.1 (FP6) - WHC (FP6) - TEC 3.9.0 - Windows 2000 Serve (SP4) When installing Endpoint on a WindowsXP pro login to Gateway is un-successful. Are there any specific Patches for WindowsXP pro endpoints? Framwork related ?? Urgent Help would be greatly appriciated! Regrds, Usman Taokeer Si3. http://att1.html Martin.Carnegie... RE:WindowsXP pro endpoint fails to login - Urgent Help! Posted: Aug 19, 2005 09:58:20 AM in response to: usman.taokeer@s...'s post Reply try looking at the lcfd.log (debug 3) on the endpoint, the gatelog on the gateway the endpoint is logging onto (debug 6) and the epmgr log on your tmr. This should tell you something. If you cannot find anything send the lcfd.log and we will see if there is something there. Oh also make sure that the lcs.login_interfaces and lcs.gateway address is being set and the last.cfg Martin Carnegie Systems Management ATCO I-Tek Phone: 780.420.5068 Pager: 780.671.2895 mailto:[email protected] ________________________________ From: [email protected] mailto:[email protected] On Behalf Of [email protected] Sent: Friday, August 19, 2005 2:12 AM To: [email protected] Subject: tme10 WindowsXP pro endpoint fails to login - Urgent Help! Hi, FW 4.1.1- ITM 5.1.1 (FP6) - WHC (FP6) - TEC 3.9.0 - Windows 2000 Serve (SP4) When installing Endpoint on a WindowsXP pro login to Gateway is un-successful. Are there any specific Patches for WindowsXP pro endpoints? Framwork related ?? Urgent Help would be greatly appriciated! Regrds, Usman Taokeer Si3. http://att1.html Althuizen, Mart... RE:WindowsXP pro endpoint fails to login - Urgent Help! Posted: Aug 19, 2005 10:05:12 AM in response to: usman.taokeer@s...'s post Reply XP Firewall maybe? _____ Van: [email protected] mailto:[email protected] Verzonden: vrijdag 19 augustus 2005 15:58 Aan: [email protected] Onderwerp: RE: tme10 WindowsXP pro endpoint fails to login - Urgent Help! try looking at the lcfd.log (debug 3) on the endpoint, the gatelog on the gateway the endpoint is logging onto (debug 6) and the epmgr log on your tmr. This should tell you something. If you cannot find anything send the lcfd.log and we will see if there is something there. Oh also make sure that the lcs.login_interfaces and lcs.gateway address is being set and the last.cfg Martin Carnegie Systems Management ATCO I-Tek Phone: 780.420.5068 Pager: 780.671.2895 mailto:[email protected] <mailto:[email protected]> _____ From: [email protected] mailto:[email protected] On Behalf Of [email protected] Sent: Friday, August 19, 2005 2:12 AM To: [email protected] Subject: tme10 WindowsXP pro endpoint fails to login - Urgent Help! Hi, FW 4.1.1- ITM 5.1.1 (FP6) - WHC (FP6) - TEC 3.9.0 - Windows 2000 Serve (SP4) When installing Endpoint on a WindowsXP pro login to Gateway is un-successful. Are there any specific Patches for WindowsXP pro endpoints? Framwork related ?? Urgent Help would be greatly appriciated! Regrds, Usman Taokeer Si3. http://att1.html Fritzsching, Co... Re:WindowsXP pro endpoint fails to login - Urgent Help! Posted: Aug 19, 2005 10:12:39 AM in response to: usman.taokeer@s...'s post Reply Usman, Is the endpoint code even installing? If you have service pack 2 on your XP machine it can cause issues with the initial install of the endpoint. The error we were seeing was something to the effect "Could not ID or not NT" We were able to get around that by modifying winstlcf. Since winstlcf is just a PERL script it is easy to modify. you need to comment out this line @out=`idlcall -v $nthostoid LCF::NTInstall::inspect $args`; This stops the inspect step in the install which seems to be the issue. We have used this modified version of winstlcf on 30 or so win XP sp2 and win 2003 sp1 (which has the same issue) and have seen no problems once the endpoint is installed. Hope this helps, Good luck Cory Fritzsching Tivoli Group U.S. Customs & Border Protection Department of Homeland Security |---------+----------------------------> | | usman.taokeer@s-i| ii.com Sent by: owner-tme10@lists .us.ibm.com 08/19/2005 04:11 AM Please respond to tme10 ---------+----------------------------> >------------------------------------------------------------------------------------------------------------------------- To: [email protected] cc: Subject: tme10 WindowsXP pro endpoint fails to login - Urgent Help! >-------------------------------------------------------------------------------------------------------------------------| Hi, FW 4.1.1- ITM 5.1.1 (FP6) - WHC (FP6) - TEC 3.9.0 - Windows 2000 Serve (SP4) When installing Endpoint on a WindowsXP pro login to Gateway is un-successful. Are there any specific Patches for WindowsXP pro endpoints? Framwork related ?? Urgent Help would be greatly appriciated! Regrds, Usman Taokeer Si3. usman.taokeer@s... RE:WindowsXP pro endpoint fails to login - Urgent Help! Posted: Aug 19, 2005 12:44:15 PM in response to: Martin.Carnegie...'s post Reply here's is the lcfd.log Aug 19 14:05:31 1 lcfd Creating service: name=lcfd, title=Tivoli Endpoint Aug 19 14:05:32 1 lcfd CacheInit: Starting new index file: C:\Program Files\Tivoli\lcf\dat\1\cache\Index.v5 Aug 19 14:05:32 1 lcfd lcfd 41100 (w32-ix86) Aug 19 14:05:32 1 lcfd Binary Dir (load_dir): 'C:\Program Files\Tivoli\lcf\bin\w32-ix86\mrt' Aug 19 14:05:32 1 lcfd Library Dir (lib_dir): 'C:\Program Files\Tivoli\lcf\bin\w32-ix86\mrt' Aug 19 14:05:32 1 lcfd Dat Dir (run_dir): 'C:\Program Files\Tivoli\lcf\dat\1' Aug 19 14:05:32 1 lcfd Cache Dir (cache_loc): 'C:\Program Files\Tivoli\lcf\dat\1\cache' Aug 19 14:05:32 1 lcfd Logging to (logfile): 'C:\Program Files\Tivoli\lcf\dat\1\lcfd.log' at level 1 Aug 19 14:05:32 1 lcfd Cache limit: '20480000' Aug 19 14:05:32 1 lcfd Cache size at initialization: '0' Aug 19 14:05:32 1 lcfd to_del_list_delete: The file by name C:\Program Files\Tivoli\lcf\dat\1\delete.txt could not be opened (fopen, 2, No such file or directory). No files were deleted. Aug 19 14:05:32 1 lcfd Windows NT 5.1 Service Pack 2 (build 2600) Aug 19 14:05:32 1 lcfd Start IPC server: port 9495 Aug 19 14:05:32 1 lcfd IPC server active Aug 19 14:05:32 1 lcfd Set run state: Login Aug 19 14:05:32 1 lcfd Clean Shutdown Aug 19 14:10:42 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 14:45:53 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 15:21:06 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 15:49:30 1 lcfd System event: Suspend Aug 19 15:49:30 1 lcfd Set run state: Standby Aug 19 15:49:30 1 lcfd Stop IPC server Aug 19 15:51:26 1 lcfd System event: Resume Aug 19 15:51:26 1 lcfd Set run state: Initializing Aug 19 15:51:26 1 lcfd Start IPC server: port 9495 Aug 19 15:51:27 1 lcfd IPC server active Aug 19 15:51:27 1 lcfd Set run state: Login Aug 19 15:51:28 1 lcfd Failed to send login: ../../src/comm/netio.c:510 cti_create_client or cti_timed_create_client : loc=3, cls=2, dec=999, sys=10065, tli=0, evt=0 Aug 19 15:56:28 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 16:31:39 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 17:06:48 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 17:41:58 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 18:17:08 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 18:52:18 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 19:27:28 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 20:02:38 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 20:37:48 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 21:12:58 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. <[email protected]> Sent by: [email protected] 19-08-05 06:58 PM Please respond to [email protected] To <[email protected]> cc Subject RE: tme10 WindowsXP pro endpoint fails to login - Urgent Help! try looking at the lcfd.log (debug 3) on the endpoint, the gatelog on the gateway the endpoint is logging onto (debug 6) and the epmgr log on your tmr. This should tell you something. If you cannot find anything send the lcfd.log and we will see if there is something there. Oh also make sure that the lcs.login_interfaces and lcs.gateway address is being set and the last.cfg Martin Carnegie Systems Management ATCO I-Tek Phone: 780.420.5068 Pager: 780.671.2895 mailto:[email protected] The information transmitted is intended only for the addressee and may contain confidential, proprietary and/or privileged material. Any unauthorized review, distribution or other use of or the taking of any action in reliance upon this information is prohibited. If you receive this in error, please contact the sender and delete or destroy this message and any copies. From: [email protected] mailto:[email protected] On Behalf Of [email protected] Sent: Friday, August 19, 2005 2:12 AM To: [email protected] Subject: tme10 WindowsXP pro endpoint fails to login - Urgent Help! Hi, FW 4.1.1- ITM 5.1.1 (FP6) - WHC (FP6) - TEC 3.9.0 - Windows 2000 Serve (SP4) When installing Endpoint on a WindowsXP pro login to Gateway is un-successful. Are there any specific Patches for WindowsXP pro endpoints? Framwork related ?? Urgent Help would be greatly appriciated! Regrds, Usman Taokeer Si3. http://att1.html Harrison Kim RE:WindowsXP pro endpoint fails to login - Urgent Help! Posted: Aug 19, 2005 12:57:07 PM in response to: usman.taokeer@s...'s post Reply Usman, Usually the error message, "duplicate label exists in ep_mgr", would mean that another endpoint was connected (or is still connecting) to the gateway with the same label as your new endpoint. The simplest fix would be to uninstall the endpoint from the XP machine and reinstall. During the reinstall, when you can specify the additional parameters, try the "-n" option to set the endpoint label manually. Here is the excerpt from the FWK 4.1 Reference manual, winstlcf section: ********************************** ?n ep_label Specifies an endpoint label provided by a user. Note: If you omit the ?n option, the endpoint label is generated automatically. If you do not specify the endpoint port number, the label is the host name of the endpoint. If you specify the endpoint port number (for example, using the ?l option), the endpoint label is generated as follows: v On Windows, the label has the format host-port. v On Linux and UNIX, the label has the format host-instance, if the instance number is greater than 1. The value of instance matches the instance number used in $LCFROOT/dat/instance. ********************************** Another option is to remove the endpoint from the gateway (hence removing the endpoint record). I would say, this may be the right thing to do if you believe that there should not be another endpoint with the same label. If you would like to try this option, then I would suggest that you stop the failing endpoint, go to the gateway machine and remove the endpoint via wdelep, and start the endpoint (hopefully it will connect now). Regards. [email protected] Sent by: [email protected] 08/19/2005 09:44 AM Please respond to tme10 To [email protected] cc Subject RE: tme10 WindowsXP pro endpoint fails to login - Urgent Help! here's is the lcfd.log Aug 19 14:05:31 1 lcfd Creating service: name=lcfd, title=Tivoli Endpoint Aug 19 14:05:32 1 lcfd CacheInit: Starting new index file: C:\Program Files\Tivoli\lcf\dat\1\cache\Index.v5 Aug 19 14:05:32 1 lcfd lcfd 41100 (w32-ix86) Aug 19 14:05:32 1 lcfd Binary Dir (load_dir): 'C:\Program Files\Tivoli\lcf\bin\w32-ix86\mrt' Aug 19 14:05:32 1 lcfd Library Dir (lib_dir): 'C:\Program Files\Tivoli\lcf\bin\w32-ix86\mrt' Aug 19 14:05:32 1 lcfd Dat Dir (run_dir): 'C:\Program Files\Tivoli\lcf\dat\1' Aug 19 14:05:32 1 lcfd Cache Dir (cache_loc): 'C:\Program Files\Tivoli\lcf\dat\1\cache' Aug 19 14:05:32 1 lcfd Logging to (logfile): 'C:\Program Files\Tivoli\lcf\dat\1\lcfd.log' at level 1 Aug 19 14:05:32 1 lcfd Cache limit: '20480000' Aug 19 14:05:32 1 lcfd Cache size at initialization: '0' Aug 19 14:05:32 1 lcfd to_del_list_delete: The file by name C:\Program Files\Tivoli\lcf\dat\1\delete.txt could not be opened (fopen, 2, No such file or directory). No files were deleted. Aug 19 14:05:32 1 lcfd Windows NT 5.1 Service Pack 2 (build 2600) Aug 19 14:05:32 1 lcfd Start IPC server: port 9495 Aug 19 14:05:32 1 lcfd IPC server active Aug 19 14:05:32 1 lcfd Set run state: Login Aug 19 14:05:32 1 lcfd Clean Shutdown Aug 19 14:10:42 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 14:45:53 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 15:21:06 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 15:49:30 1 lcfd System event: Suspend Aug 19 15:49:30 1 lcfd Set run state: Standby Aug 19 15:49:30 1 lcfd Stop IPC server Aug 19 15:51:26 1 lcfd System event: Resume Aug 19 15:51:26 1 lcfd Set run state: Initializing Aug 19 15:51:26 1 lcfd Start IPC server: port 9495 Aug 19 15:51:27 1 lcfd IPC server active Aug 19 15:51:27 1 lcfd Set run state: Login Aug 19 15:51:28 1 lcfd Failed to send login: ../../src/comm/netio.c:510 cti_create_client or cti_timed_create_client : loc=3, cls=2, dec=999, sys=10065, tli=0, evt=0 Aug 19 15:56:28 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 16:31:39 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 17:06:48 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 17:41:58 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 18:17:08 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 18:52:18 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 19:27:28 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 20:02:38 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 20:37:48 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. Aug 19 21:12:58 1 lcfd Terminating login from 192.168.1.209+9495 (Adil-SDPM): duplicate label exists in ep_mgr. <[email protected]> Sent by: [email protected] 19-08-05 06:58 PM Please respond to [email protected] To <[email protected]> cc Subject RE: tme10 WindowsXP pro endpoint fails to login - Urgent Help! try looking at the lcfd.log (debug 3) on the endpoint, the gatelog on the gateway the endpoint is logging onto (debug 6) and the epmgr log on your tmr. This should tell you something. If you cannot find anything send the lcfd.log and we will see if there is something there. Oh also make sure that the lcs.login_interfaces and lcs.gateway address is being set and the last.cfg Martin Carnegie Systems Management ATCO I-Tek Phone: 780.420.5068 Pager: 780.671.2895 mailto:[email protected] The information transmitted is intended only for the addressee and may contain confidential, proprietary and/or privileged material. Any unauthorized review, distribution or other use of or the taking of any action in reliance upon this information is prohibited. If you receive this in error, please contact the sender and delete or destroy this message and any copies. From: [email protected] mailto:[email protected] On Behalf Of [email protected] Sent: Friday, August 19, 2005 2:12 AM To: [email protected] Subject: tme10 WindowsXP pro endpoint fails to login - Urgent Help! Hi, FW 4.1.1- ITM 5.1.1 (FP6) - WHC (FP6) - TEC 3.9.0 - Windows 2000 Serve (SP4) When installing Endpoint on a WindowsXP pro login to Gateway is un-successful. Are there any specific Patches for WindowsXP pro endpoints? Framwork related ?? Urgent Help would be greatly appriciated! Regrds, Usman Taokeer Si3. http://att1.html joel.n.mokoetle... RE:WindowsXP pro endpoint fails to login - Urgent Help! Posted: Aug 19, 2005 12:58:14 PM in response to: usman.taokeer@s...'s post Reply Does "wep ls -i ip,label | grep 192.168.1.209" return any label? If so delete the endpoint with "wdelep <ep_label>", sync your epmgr with fsck, and also run sync_gateways. Then clean your TMA code at the target machine, and retry install(you could just delete the id file in the lcf dat directory and verify your last.cfg has appropriate info for your target tmr, then restart lcfd). Hope that helps, Napo *************************************************************** JPMorganChase - Systems & Service Management Tools Engineer Tel: 614-213-8599 Pager: 888-636-2381 "Not all infinite objects are of the same size"

Recommended Links

Softpanorama Recommended

Top articles

Sites

Maintenance and Troubleshooting Guide / Troubleshooting endpoints

When determining problems with the endpoint, it is important to remember that the endpoint operates in conjunction with two other components of the Tivoli environment: the endpoint manager and the gateway. Therefore, you need to assess the state of several Tivoli Management Framework components when troubleshooting endpoints: the endpoint itself, the gateways it can connect to, and the endpoint manager that is on the Tivoli server.

This chapter contains the following sections:

• General troubleshooting procedure for endpoints
• Using log files to troubleshoot endpoints
• Common difficulties with endpoint login
• Common difficulties after endpoint login
• Performance considerations with endpoints
• Endpoints and policy regions
• Deleting endpoints

FAQShop.com Welcome to the Tivoli Section

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