Tuesday, 22 July 2014

IBM HTTP Server - Rewriting HTTP (port 80) requests to HTTPS (port 443)

Rewriting HTTP (port 80) requests to HTTPS (port 443)

The rewrite module (mod_rewrite.c) provided with the IBM® HTTP Server can be used as an effective way to automatically rewrite all HTTP requests to HTTPS.

The rewrite module (mod_rewrite.c) can be used to automatically rewrite all HTTP (port 80) requests to HTTPS (port 443). This provides an effective way to ensure that all traffic to and from the IBM HTTP Server is encrypted over the Secure Sockets Layer (SSL) without having to use individual redirects or hard-coded HTTPS links. 

From IBM WebSphere CloudBurst Appliance to IBM PureApplication Service on SoftLayer

From the IBM PureSystems Blog: -


Over the past five years, IBM has made a significant contribution to the cloud computing space. Specifically, IBM developed and delivered several appliances and rack solutions. Figure 1 shows a timeline on three products.

http://expertintegratedsystemsblog.com/wp-content/uploads/2014/07/IPAS-history-timeline-300x152.png

Knowledge Collection: Security documents for the IBM Business Process Manager products

This knowledge collection is a focused compilation of links to security-related documents for the IBM Business Process Manager products.

This is applicable to IBM BPM versions 7.5, 7.5.1, 8.0, 8.0.1, 8.5 and, 8.5.5.

DB2 - HADR Performance Tuning and Diagnostics

When the DB2 HADR feature is enabled, the primary database's transaction logs are replicated to one or more standby databases in real time. The replication provides HA and DR protection, at a cost. The replication adds overhead to the primary's log writing. Applications on the primary may exprience slow down. This article will focus on HADR performance specifically.

This article consists of three main sections:
- Configuring HADR for Optimal Performance: Preventive Care
- Monitoring HADR Performance: Get early warning of problems
- Diagnosing and fixing HADR performance problems: When a problem does occur, how to fix it.

A spot of IBM Tivoli Monitoring ...

This is an ongoing Work-in-Progress

The context is that we're looking at solutions to monitor a number of components, including base OS installations, IBM WebSphere Application Server, plus ancillary software, including IBM HTTP Server and the IBM WebSphere Plugin.

We're looking at feeding monitoring events back to Tivoli Monitoring, specifically Tivoli Enterprise Monitoring Server (TEMS), including OS-level activities ( Tivoli Monitoring Agent for Linux ) and log files ( Tivoli Log File Agent ).

IBM Tivoli Monitoring Wiki

Welcome to the IBM Tivoli Monitoring (ITM) WIKI. IBM Tivoli Monitoring products and solutions can help you manage the performance and availability of a wide range of distributed operating systems and applications.  This WIKI will provide you with valuable information and guidance on currently available IBM Tivoli Monitoring products and solutions.


The articles here provide valuable information related to monitoring agents.

Components of the monitoring agent

After you install and set up the Monitoring Agent for Linux OS (product code: klz or lz), you have an environment with a client, server, and monitoring agent implementation for IBM Tivoli Monitoring.

This IBM Tivoli Monitoring environment contains the following components:

• Tivoli Enterprise Portal client with a Java-based user interface for viewing and monitoring your enterprise.
• Tivoli Enterprise Portal Server that is placed between the client and the Tivoli Enterprise Monitoring Server and enables retrieval, manipulation, and analysis of data from the monitoring agents.
• Tivoli Enterprise Monitoring Server, which acts as a collection and control point for alerts received from the monitoring agents, and collects their performance and availability data.
• Monitoring Agent for Linux OS, which collects and distributes data to a Tivoli Enterprise Monitoring Server. This component also embeds the Agent Management Services function.
• Operating system agents and application agents installed on the systems or subsystems you want to monitor. These agents collect and distribute data to the Tivoli Enterprise Monitoring Server.
• Tivoli Data Warehouse for storing historical data collected from agents in your environment. The data warehouse is located on a DB2®, Oracle, or Microsoft SQL database. To collect information to store in this database, you must install the Warehouse Proxy agent. To perform aggregation and pruning functions on the data, install the Warehouse Summarization and Pruning agent.
• Tivoli Enterprise Console event synchronization component for synchronizing the status of situation events that are forwarded to the event server. When the status of an event is updated because of IBM® Tivoli Enterprise Console® rules or operator actions, the update is sent to the monitoring server, and the updated status is reflected in both the Situation Event Console and the Tivoli Enterprise Console event viewer. For more information, see IBM Tivoli Monitoring Installation and Setup Guide.


The Log File Agent is based on ITM autonomous agent technology (Autonomous agents don't require a full ITM installation) and is designed to monitor log entries on Windows, UNIX and Linux platforms from the following sources:

• Text log files
• Windows Event Logs
• UNIX/Linux Syslog

The Tivoli Log File Agent (product code LO) provides you with the capability to monitor Application log
files.

IBM Tivoli Monitoring is the base software for the Log File agent.

The Tivoli Log File Agent is an agent that provides a configurable log file monitoring capability that uses
regular expressions. For compatibility, the agent can consume the configuration information and format
strings previously used by the Tivoli Event Console Log File Adapter. These strings allow the agent to
filter the log data according to patterns in the format file, and submit only the interesting data to an
event consumer. The agent can send data both to a Tivoli Enterprise Monitoring Server or through the
Event Integration Facility (EIF) to any EIF receiver, such as the OMNIbus EIF probe.


The Tivoli Log File Agent (product code LO) provides you with the capability to monitor Application log files.

IBM® Tivoli® Monitoring is the base software for the Log File agent.

The Tivoli Log File Agent is an agent that provides a configurable log file monitoring capability that uses regular expressions. For compatibility, the agent can consume the configuration information and format strings previously used by the Tivoli Event Console Log File Adapter. These strings allow the agent to filter the log data according to patterns in the format file, and submit only the interesting data to an event consumer. The agent can send data both to a Tivoli Enterprise Monitoring Server or through the Event Integration Facility (EIF) to any EIF receiver, such as the OMNIbus EIF probe.


Thursday, 17 July 2014

Mac OS X - Applications and File Types - Changing the system-wide default

I inadvertently changed the default application for file type .RFT ( Revisable Form Text ) from TextEdit to OpenOffice.

This was, of course, an error.

Whilst I knew how to change the default for each individual file, I couldn't work out how to change the default for all files back to TextEdit.

This blog post came to my rescue: -


Thanks be to David Kirk :-)

Wednesday, 16 July 2014

IBM Elastic Caching Community

Thanks to my IBM colleague, Jonathan Marshall: -


The future of the web is scale.  And when we're talking solving big problems, we mean, eXtreme Scale.  Large Volumes, Highly Available, Reliable, Transparent, High Performance, Scalable, Accessible, Secure, Usable, and Inexpensive are just a few of the benefits of using elastic caching.  
Data in memory is much quicker and easier to access than memory on disk. End user response times and system throughput are improved. Load on backend EIS and databases are reduced by large memory caches, thus increasing the workload you may process and your scalability. 

WebSphere eXtreme Scale provides huge memory stores on commodity hardware solving all these problems being a dynamic, elastic cache. What can't you do with large, cheap memory stores?