Tivoli TEC Logfile Adapter

The TEC logfile adapter is used to relay events from the clients to the TEC event server.  It also can be installed on the TEC server itself.  ACP is much more powerful and using the latest version very scalable and easy to configure. There are two types of logfile adapter: TME and and not-TME

• The TME  (IBM-speak for a server where TEC is installed, yu can check it in  ) logfile adapter receives stream of raw log file information from the UNIX syslogd daemon via a named pipe, formats it, and sends relevant events to the TEC gateway, which  then sends the information to the event server.  AIX is deficient in this respect and you need first to enable the syslogd daemon on it. Also you need to create a converter from AIX errdaemon logs to syslogd logs.
• The non-TME UNIX logfile adapter sends information directly to the event server. Other than that it is identical to its TME-based brother.

During the installation the UNIX logfile adapter  modifies the /etc/syslog.conf file to enable the named pipe that the adapter uses.

The adapter can also be configured to monitor any ASCII log file for information that is important to the operation of your enterprise. For example TWS uses logfile adpater to send events to about job execution to TEC. See TWS Logfile adapter. Installation of TWS adapter comes with more interesting set of rules that syslog adapter and I recommend to study them first.

Typical operations with adapter include

• Starting the adapter
• Stopping the adapter
• Reloading the logfile adapter configuration 
• Restarting the adapter

Operations with Logfile Adapter: Starting, Stopping and Reloading

Starting the logfile adapter

Use the init.tecad_logfile start [adapterID] command in the background to manually start the adapter. Always use this command to ensure that the syslogd daemon is properly configured to send messages to the adapter. For example

cd /opt/tivoli/lcf/bin/aix4-r1/TME/TEC/adapters/bin/

init.tecad_logfile start &

In most situations, the start-up process takes approximatly 40 seconds, at which time the syslogd daemon is refreshed. If you want to give the adapter additional seconds to complete its startup, specify the -tstartup_time option for the init.tecad_logfile start command. There cannot be a space between the option letter and the option value. This option is useful if the adapter does not receive events because the syslogd daemon is not properly refreshed.

Note: The endpoint adapter is automatically started as a step in the adapter installation process when the adapter configuration profile is distributed using the Adapter Configuration Facility.

The syntax for the init.tecad_logfile command is as follows:

init.tecad_logfile [-s] {start | stop} [adapterID] &

If the -s flag (skip syslog) is specified, the adapter does not monitor the syslogd daemon.

If the -s flag is not specified, use & so that the command runs in the background while returning a command prompt to your session. Otherwise, because an adapter started without the -s option forks a child process to run the adapter, the process does not return to the command line until the child process ends.

If you start the adapter with the -s flag, you should also use the -s flag when you stop the adapter to avoid reconfiguring the syslogd daemon. You can also stop the adapter without the -s flag and it still works. However, do not stop an adapter with the -s flag if you did not start it with the -s flag.

If the -s flag is not specified, the UNIX logfile adapter startup script uses a UNIX pipe to monitor the syslogd daemon and the syslogd daemon is configured to write to the pipe, and the UNIX logfile adapter reads from that pipe. When the adapter ends, the startup script reconfigures the syslogd daemon to stop writing to the pipe before stopping the UNIX logfile adapter.

The following command starts a UNIX logfile adapter called syslog that monitors all syslog messages:

init.tecad_logfile start syslog &

See also Starting the adapter

Stopping the logfile adapter

To manually stop the adapter

init.tecad_logfile stop [adapterID]

command. This command ensures that the syslogd daemon is correctly configured to stop sending messages to the adapter. If the adapter is stopped with any other method, the syslogd daemon might exit because the adapter is no longer listening on the named pipe that the syslogd daemon is writing to.

See also Stopping the adapter

Reloading the logfile adapter configuration

To reload the adapter configuration and format files, issue the following command:

kill -HUP pid

where pid is the process ID of the adapter. Use this command if you want to change the adapter configuration without having to stop and restart the adapter. For example, you might want to temporarily add (and later remove) filters or entries in the format file when the system goes into maintenance mode. After you have made the necessary changes to the configuration and format files, issue this command to dynamically update the adapter configuration.

You can automatically stop the endpoint adapter by distributing an adapter configuration profile that has the adapter start command removed from the after-file-distribution actions. See Adapter Configuration Facility for additional information.

Restarting the adapter

Sometime the adapter becomes stale. That was a common error with TWS 8.2: once in several months transmission of TWS messages to TEC console was dramatically delayed. In this case you need to restart the logfile adapter

cd /tivoli/lcf/bin/aix4-r1/TME/TEC/adapters/bin/
./init.tecad_logfile -s stop &&  ./init.tecad_logfile -s start &

Installation

A set of configuration steps must be performed to enable logadapter adapter. IBM⁽ Tivoli Enterprise Console Installation Guide is almost useless as for installation. The key idea is that you need to create a profile and distribute it to endpoints. Distribution of profile actually creates the logadapter files.

The first step is to create an Adapter Configuration Profile (ACP). In order to do so, you must insure that ACPs are managed resources. From the pull-down menu on the selected policy region, select Managed Resources and make sure ACP is in the Current Resources list.

• Open an existing Profile Manager or create a new one. Since you will be monitoring endpoints, make it dataless.
• Open the Profile Manager. Create a new profile of type ACP by selecting the Create button.
• Open the Profile Manager. From the Profile pull-down menu, select Edit Profile.
• Select Add Entry. Choose the appropriate one for your target, in this case, tecad_nt.
• The graphic below illustrates editing the profile entry to point to the log file generated by your application. This log file will be on the endpoint you are monitoring.

  Select the Environment button to view the contents of the configuration file.

  In the Unset Variables list, notice the variable LogSources. This keyword is used to specify the location of the log file to be used for input. Select it and set it to the correct file name.

  Double-click LogSources to change it. Fill in the full path name to your log file in the right text box. Verify that your change is reflected in the Current EIF Environment window above.

  In summary, you have created a Profile Manager and an ACP Profile. ACP is required to distribute adapters to endpoints. This is the mechanism used to distribute the format file that converts log file entries into events. There are other benefits of profiles--subscriptions lists, policies, and before and after scripts.

  An important step in this process is to modify the configuration file, so the Logfile Adapter is targeted at your application's output. (Multiple instances of the Logfile Adapter can monitor different files, so you don't lose the provided logfile capabilities.)

  Distributing the Logfile Adapter Profile

  In order for the changes you have made to take effect, the profile must be distributed to an endpoint. If you want to monitor a managed node, you can make it an endpoint as well.

  1. Make sure the Subscription list is accurate.
  2. From the Profile Manager pull-down menu, select Subscribers.
  3. Select Profile Manager Distribute.
  4. Select the subscriber.
  5. Click Distribute Now.

After the format files have been distributed, the events generated from logfile entries should show up in the event console. When the adapter configuration is distributed, the Logfile Adapter for the subscribe endpoint will automatically restart the adapter with the new configuration file. Add entries to the log file to generate new events.

Adapter files

The UNIX logfile adapter package consists of the following files:

1. tecad_logfile.conf The configuration file. This file along with format file is the most important for the adapter configuration. It is located at /opt/tivoli/lcf/bin/platform/TME/TEC/adapters/etc
2. tecad_logfile.fmt The format file. The second most important file for the adapter. Provide parsing of log entries using an ideosyncratic language. It is also located at /opt/tivoli/lcf/bin/platform/TME/TEC/adapters/etc
3. log_default.rls The default rule file. Located in rules directory of TEC server.
4. tecad_logfile.baroc The BAROC file. Located in BAROC directory of TEC server.
5. tecad_logfile.cfg The installation script.
6. init.tecad_logfile The adapter startup and shutdown script. Never stop the adapter using signals. Use this script to ensure that the syslogd daemon remains running and functional.
7. tecad_logfile The executable file of the adapter that receives the log information and transforms it into events.
8. logfile_gencds The executable file that converts a format file to a CDS file.
9. tecad_logfile.cds The CDS file. This file is created by running logfile_gencds on the format file.
10. tecad_logfile.err The error file.
11. [email protected] cache file; location is defined in tecad_logfile.conf By default is located at /etc/Tivoli/tec/

Before you start the event server and UNIX logfile adapter, check each adapter file to determine if it defines the behavior you want from the adapter.

See also Adapter files

Configuration file

The configuration file defines the behavior of the adapter. The configuration file can have the common keywords described in Configuration file, as well as the following custom keywords:

LogSources

Specifies the log files to poll. The complete path to each file must be specified, and file names must be separated by commas. Within each file name, you can also use an asterisk (*) to represent any sequence of characters, or a question mark (?) to represent any single character. For example, mylog* would result in polling all log files whose names begin with mylog, while mylog??? would result in polling all log files whose names consist of mylog followed by exactly three characters. These wildcard characters are supported only within the file name; the path must be explicitly specified.

A log source need not exist when the adapter is started; it is polled when it is created.

Each line in the file must end with a newline character. If a file truncates while the adapter is active, the adapter automatically resets its internal pointer to the beginning of the file. If during the polling interval the file is overwritten, removed, or recreated with more lines than the previous poll, only the number of lines greater than the previous line count is read. For example, the file has one line. After the poll interval elapses, the file is overwritten with two lines. Only the second line is read on the next polling.

Note:

The maximum number of lines that can be concatenated to a log file is 16 384.

NewLogBasedOn

Specifies whether a log file should be treated as new when the time stamp of the file changes but the size remains the same. When a file is treated as new, the adapter re-sends every event contained in the file. The possible value is:

mtime | MTIME

The file is treated as new if the modification time stamp changes.

This keyword is optional. If NewLogBasedOn is not specified, a preexisting log file is treated as new only if its size decreases.

PollInterval

Specifies the frequency, in seconds, to poll each file listed in the LogSources field for new messages. The default value is 120 seconds.

ProcessPriorityClass

Specifies the process priority for the adapter. You can adjust this value to improve system performance if the adapter processes large volumes of events and is using too many processor resources. The possible values are:

A

Very low priority (20)

B

Low priority (10)

C

Typical priority (0)

D

Above typical priority (-5)

E

High priority (-10)

F

Very high priority (-20)

The default value is C (typical priority).

UnmatchLog

Specifies a file to log discarded events that cannot be parsed into a Tivoli Enterprise Console event class by the adapter. The discarded events can then be analyzed to determine if modifications are needed to the adapter format file.

See also Configuration file

Running multiple UNIX logfile adapters

You can run multiple instances of the UNIX logfile adapter on a single system. It is recommended that additional adapters be run as non-TME adapters. To monitor different log files, each instance of the adapter must have its own configuration, format, class definition statement (CDS), and error files. If the adapters use event buffering (set using the BufferEvents keyword, which has a default value of YES), the adapters must also have their own cache files.

If you want to stop an adapter when multiple log files are running, you must specify the name of the adapter to stop. If you do not specify the adapter to stop, the default adapter without a name is stopped.

Format file

The format file is described in detail in Format file.

Class definition statement file

The CDS file defines how an adapter constructs events. This file is derived from the format file using the logfile_gencds program. In general, you should never have to edit this file to add new mappings. The CDS file is described in detail in Class definition statement file and in Appendix C. Class definition statement file reference.

Error file

The error file is described in detail in Error file.

Events listing

The following table shows the class names and severities of all events defined for the UNIX logfile adapter. You can use the table to get a sense of how log file events are mapped to Tivoli Enterprise Console events and to determine if you want to make any changes. The events are defined in the BAROC file. See the IBM Tivoli Enterprise Console Rule Developer's Guide for more information about customizing BAROC files.

Event class structure

Event classes are defined hierarchically, with child classes inheriting attribute value defaults from the parent.

The adapter fills in the following attribute defaults. The attributes are used in event group filters.

• source: LOGFILE
• origin: hostIPaddress
• hostname: hostname

The following events are defined for the UNIX logfile adapter in the tecad_logfile.baroc file.

Default rules

The UNIX logfile adapter has a set of default rules that can be installed to enhance event server operation. Rules can enable the server to perform functions such as deleting events and sending e-mail to alert administrators of an unresolved problem. The rules are contained in the log_default.rls file and perform the following functions:

• Duplicate events of the following classes are filtered out and the first event repeat count is increased:
  • Printer_Paper_Out
  • Printer_Toner_Low
  • Printer_Offline
  • Printer_Output_Full
  • Printer_Paper_Jam
  • Printer_Door_Open
• Printer assistance can be called for when a printer condition persists for a period of time greater than 90 seconds. If any of the following conditions persist for that period of time, an e-mail message is sent to the e-mail alias tec_print to request assistance with the printer condition. (The tec_print alias must be added to the e-mail alias file before the messages can be delivered.)
  • Printer_Paper_Out
  • Printer_Toner_Low
  • Printer_Offline
  • Printer_Output_Full
  • Printer_Paper_Jam
  • Printer_Door_Open
• When a printer condition is cleared, the event server automatically closes the event that indicated a problem. If e-mail was sent out notifying the administrators of the printer problem, the server sends e-mail indicating the condition has cleared up.
• The Su_Success and Su_Failure events indicate that a user attempted to use the su command. If a Su_Success event is received within 90 seconds of the Su_Failure event, the server assumes that the Su_Failure was a mistake and downgrades the event to HARMLESS and closes the Su_Failure event. The rules ensure that these two events are related by checking that they occurred on the same host, the user attempting this was the same, and the user that they were trying to change to was the same.
• Some of the log file events are relevant for a short amount of time. The administrators also do not want to be burdened with closing these events manually. A rule is provided that closes the following event classes after one hour. You can edit this rule to change the time or the list of classes. Refer to the IBM Tivoli Enterprise Console Rule Builder's Guide for information about editing rules.
  • Logfile_Amd
  • Logfile_Cron
  • Logfile_Oserv
  • Logfile_Date_Set

The event server also comes with some additional rules that you can install. The $BINDIR/TME/TEC/contrib/rules/security directory contains the security_default.rls file, which provides the following behavior to the event server:

• When a host reports a repeated login failure attempt at least two times in a row, e-mail is sent to the e-mail alias tec_security notifying the administrators of the attempted security breach. (The tec_security alias must be added to the e-mail alias file before the messages can be delivered.)
• A rule is included that closes the following event classes after one hour:
  • Repeated_Login_Failure
  • Repeated_Login_Failure_From
  • Root_Login_Success_From

See also Default rules

NEWS CONTENTS

• 200102 : Tivoli-IBM TME10 FAQ - ( Apr 8, 2003 , Tek-Tips )

Old News ;-)

Tivoli-IBM TME10 FAQ - How do I create a logfile adapter to read UNIX application logfiles?

Apr 8, 2003 | Tek-Tips

First, create a format file for your application. Note that you must have a default Sun syslog or AIX errpt logfile adapter deployed before you can do this, and you will need to do some scripting to install your application LFA in a different location. If you fail to do this, the application LFA will break your syslog adapter.

Define a base event class if you have multiple event formats with common attributes:

FORMAT Nortel_IVR_Base
%s %t <%s> %s %s*
hostname "HSTNAME"
sub_origin "N/A"
adapter_host "EPLABEL"
date $2
origin DEFAULT
sub_system $3
error_code $4
msg $5
END

Then begin defining your events:

// Sat Aug 17 10:55:56 <KmnPin> 91003 Line 25 Host 1 Severity 8 Vps 1
FORMAT Nortel_IVR_Error FOLLOWS Nortel_IVR_Base
%s %t <%s> %s Line %s Host %s Severity 8 %s*
-line_number $5
-host_number $6
vps_number $7
msg PRINTF("<%s> %s Line %s %s", sub_system, error_code, line_number, vps_number)
END

Note the dashes "-" before some of the slots. These signify event slots that are used locally and are not present in the BAROC file.

Create your Adapter Configuration Profile
Select the adapter type - a default AIX or Solaris type will do.

In the "Filters" tab, create your event filters.

000 Class=Nortel_IVR_Base
001 Class=Nortel_IVR_Error

In the "Environment" tab, set your keywords

AdapterErrorFile=/usr/Tivoli/lcf/bin/solaris2/TME/TEC/adapters/IVR_Logfile/etc/tecad_logfile.err
BufEvtPath=/usr/Tivoli/lcf/bin/solaris2/TME/TEC/adapters/IVR_Logfile/tecad_logfile.cache
BufferEvents=YES
MaxEventSize=4096
FilterMode=IN
LogSources=/opt/vps/vps33/log/alarm.log
PollInterval=30
ServerLocation=@EventServer

Note the use of the FilterMode keyword. FilterMode=IN will only process events are present in the event classes in the "Filters" tab. The default behavior is FilterMode=OUT.

If you have multiple logs, you must specify the full path to each logfile, separated by commas with no spaces in between.

In the "Actions" tab for the "Before" actions I do a little scripting in the adapter to create the LFA install directory and copy the necessary LFA binaries to the new LFA install directory.

TECADHOME=/usr/Tivoli/lcf/bin/solaris2/TME/TEC/adapters/IVR_Logfile
export TECADHOME
mkdir -p $TECADHOME/etc
mkdir -p $TECADHOME/bin
unset CHILD_OF_OSERV
cp $LCF_DATDIR/../../bin/solaris2/TME/TEC/adapters/bin/* $TECADHOME/bin
$TECADHOME/bin/init.tecad_logfile -s stop IVR_Logfile

Note:
You must use the "-s" switch in the adapter stop command to let the adapter know NOT to create a pipe to syslogd! If you don't, you'll break your syslog adapter.

Ok, here's where it gets tricky. In the "After" actions, we define some variables, then use sed to insert those variables into a temporary format file, then compile the temp format file and the finished format file:

TECADHOME=/usr/Tivoli/lcf/bin/solaris2/TME/TEC/adapters/IVR_Logfile
export TECADHOME
unset CHILD_OF_OSERV
REALNAME=`hostname`
export REALNAME
/usr/bin/sed -e "s/HSTNAME/$REALNAME/g" $TECADHOME/etc/tecad_logfile_IVR.fmt > $TECADHOME/etc/tecad_logfile.fmt.tmp
/usr/bin/sed -e "s/EPLABEL/${ACPEP_NAME}/g" $TECADHOME/etc/tecad_logfile.fmt.tmp > $TECADHOME/etc/tecad_logfile.fmt
logfile_gencds $TECADHOME/etc/tecad_logfile.fmt > $TECADHOME/etc/tecad_logfile.cds
$TECADHOME/bin/init.tecad_logfile -s start IVR_Logfile

Again, make sure you're using the "-s" switch on the adapter start command.

The reason for all of this scripting is to ensure that if the hostname differs from the endpoint lable, we can tell that when we look at the event. This is helpful in clustered or HACMP configurations where you may have multiple endpoints installed.

In the "Distribution" tab, tell the adapter where it's going to get its format and error files from:

tecad_logfile.err=FQDN:/usr/Tivoli/bin/generic_unix/TME/ACF_REP/tecad_logfile.err
tecad_logfile_IVR.fmt=FQDN:/usr/easm/dev/adapter/IVR_Logfile/tecad_logfile_IVR.fmt

In the "General" tab, set the install location for the adapter's configuration files:

Install dir: /usr/Tivoli/lcf/bin/solaris2/TME/TEC/adapters/IVR_Logfile/etc

Config file: tecad_logfile.conf

Make sure your event class is added to a new or existing BAROC file. Compile your rulebase and bounce the TEC server.

Save your adapter and distribute. That is, after you've added your subscribers.

Recommended Links

2005_06_28 STE: Tivoli Enterprise Console Adapter Implementation

Support Technical Exchange presented by Kandasamy Kandavel to show overview, installation, files, event filtering, troubleshooting and internationalization of the Tivoli Enterprise Console Logfile Adapter.

Debugging Tivoli Enterprise Console 3.9 logfile adapter problems by Sandi Comsudi

Plus Module User's Guide - good description of integration of TWS with TEC using logfile adapter.

Adding a new message to a Logfile Adapters Provides an explanation of how to add new messages to be processed by the Unix Logfile adapter or the NT Event Log Adapter.

Etc

• Running the tecad_logfile.cfg file from any directory other than the $TECADHOME/bin directory fails with a syntax error similar to the following example:

  It looks like TECADHOME=/opt/TMF/bin/lcf_bundle/bin/platform

  If run from $TECADHOME it generates something like:

 #Start the Tivoli Enterprise Console Logfile Adapter
if [ -f /opt/TMF/bin/lcf_bundle/bin/aix4-r1/TME/TEC/adapters/bin/init.tecad_logfile ]; then
    sleep 2
    /opt/TMF/bin/lcf_bundle/bin/aix4-r1/TME/TEC/adapters/bin/init.tecad_logfile  start  &
    echo "Tivoli Enterprise Console Logfile Adapter started."
fi

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