Alex Scoble's IT Notes - An Information Technology Blog

Restoring a MySQL database from files

If you are a relative MySQL newbie like me, and someone tells you to backup your databases, you might make the same mistake that I did and copy the database files (all of those .frm, MYD and .MYT files) to a backup folder instead of using MySQL's built in backup method.

Of course, when you make this kind of mistake, often you are required to restore from backups, so you copy the files back to their original location and MySQL bombs on you when you try to start it.

In my case, I backed up the entire /var/lib/mysql directory to /tmp/mysql-backups. When I copied the /tmp/mysql-backups stuff back to /var/lib/mysql, nothing worked. Doing a 'cat /var/log/mysqld.log' showed a "Can't find file: './mysql/plugin.frm' (errno: 13)" error.

Turns out that you have to reset permissions on those files and do some work with SELinux to get that to allow the mysql account to access the databases.

This help is specific to MySQL using InnoDB on CentOS 6.x. I have no way of knowing if it will work for any other configurations.

Here's how to restore your databases and reset the permissions assuming that you have a backup of the entire /var/lib/mysql directory. I'm going to do a bunch of similar chown/chmod statements below just to be sure. You could do the same thing by doing
'chown -R mysql:mysql <directory>' and you'll want to do the separate commands for chmod since the directories and files should have different allowed operations.

rm -rf /var/lib/mysql
mkdir /var/lib/mysql
cp -r /tmp/mysql-backups/* /var/lib/mysql
chown mysql:mysql /var/lib/mysql
chown mysql:mysql /var/lib/mysql/*
chmod 660 /var/lib/mysql/*
chown mysql:mysql /var/lib/mysql/mysql
chmod 700 /var/lib/mysql/mysql
chown mysql:mysql /var/lib/mysql/mysql/*
chmod 660 /var/lib/mysql/mysql/*

Do the chown and chmod commands as shown for any other directories that you have under /var/lib/mysql

If you tried to start mysql right now, you'd still get the same error though if you have SELinux turned on, so now we have to fix that.

chcon -v --type=mysqld_db_t /var/lib/mysql
chcon -v --type=mysqld_db_t /var/lib/mysql/*
chcon -v --type=mysqld_db_t /var/lib/mysql/mysql
chcon -v --type=mysqld_db_t /var/lib/mysql/mysql/*

And so forth for any directories that you have under /var/lib/mysql

If you started mysql now, you'd see this error now "[ERROR] Can't start server : Bind on unix socket: Permission denied". SELinux is still blocking access so now you have to do the following:

semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"
restorecon -Rv /var/lib/mysql

It is likely that you will only have to do the 'restorecon' command above, but I'm being thorough here.

You can now start the mysql service ('service mysqld start') and it should work without issues.

Patching is killing Windows (AKA the problem that Microsoft MUST solve in order to remain competitive)

I wrote a blog post back in 2005 on my Computerworld blog detailing 4 things that I thought that Microsoft needed to fix in Windows in order to remain competitive. Unfortunately, the biggest thing on that list, the land of a thousand reboots, hasn't gotten much better.

Right now, one of my main functions at my job is to manage patches for nearly a thousand Windows systems. "Pain in the ass" doesn't even begin to describe the difficulties of patching that many Windows servers and workstations.

First off, you can't do it without an enterprise tool like LANDesk, Secunia, GFI LANGuard, Microsoft SCCM, etc. These tools are big, complex, hard to manage and typically require agents which often have their own issues.

Second, the number of third party apps that you have to track and patch is significant and growing. Because of compliance requirements, some organizations have to assess every single "security patch" for applicability. To do this, you have to know every piece of software that you have installed in areas requiring compliance and you have to regularly search for security updates to all of those applications. Yes, it is as laborious and mind numbing as it sounds. I have a lot of fun at my job, but this area is totally not intellectually stimulating at all.

Third, because of the fact that Windows patches require a reboot, scheduling downtime of critical production systems can be a total nightmare.

I should mention right now that Linux does all of this far better. If you pick your tools right (limit the tools that can't be installed from a repository), you manage all of your patching from one place. Yum for RedHat/CentOS or Aptitude for Debian. If your server is headless (who needs a GUI that takes up all of those resources and adds another 200 packages that need to be updated), patching a brand new server up to current takes minutes and requires ZERO reboots. It's as easy as typing "yum update". Since it can be used to track what security patches are applicable for each system, there's no research that needs to be done on just about anything other than the stuff that you installed from source.

Linux is quite simply light years ahead of Windows in this area. It is probably the main reason that I'm getting into Linux so much of late.

It sometimes takes over an hour to install a service pack on a Windows server. I can build up a new Linux server and fully patch it in less time. In fact, I can build up a new server with the LAMP stack, install an app on top of that (for log management, for instance) AND fully patch it in less time.

It's no wonder that Microsoft's share of datacenter systems has remained weak and will continue to slide. This situation is unacceptable. Even with clustering, which is expensive, hard to maintain and requires a lot more hardware, Microsoft can't maintain the kind of uptime that Linux is able to. Because guess what, patching invariably BREAKS your cluster.

On Windows 7, it can take over an hour to fully patch a new laptop or workstation and thats with SP1 already installed.

Even a shark with a congested nose can smell the blood in the water.

Linux administrators are able to perform patch management on their systems without buying expensive tools, without wasting a lot of time performing CVE and NVD searches for their apps, with a minimal amount of downtime and with significantly lower risk to their systems. Not to mention that it's much easier to deal with patching of systems isolated from the internet because you can build your own repositories.

Microsoft will continue to bleed marketshare and loyal customers like me until they solve this problem.

It will likely take a complete rewrite of Windows to do it, but given that the survival of the company depends on it, at least in my opinion, it would be stupid of them not to do it and soon.

I won't hold my breath though.

Installing Zabbix agent on Debian

I could not find a tutorial that showed how to install the precompiled Zabbix 2.0 agents on a 64 bit Debian box, so I'm making one here.

The latest downloads for precompiled agents and source code for building servers is here. http://www.zabbix.com/download.php

On the Debian system that is getting the agent (remember this is for 64 bit version of Debian, go to the Zabbix download site for the link to the 32 bit agent if your system is 32 bit):

We need both the precompiled agent and the source files

You should be logged in to a root sudo or su session for the following

cd $HOME

wget http://www.zabbix.com/downloads/2.0.0/zabbix_agents_2.0.0.linux2_6_23.amd64.tar.gz

wget http://downloads.sourceforge.net/project/zabbix/ZABBIX%20Latest%20Stable/2.0.0/zabbix-2.0.0.tar.gz

mkdir zabbix

cd zabbix

tar -xzvf ../zabbix_agents_2.0.0.linux2_6_23.amd64.tar.gz

tar -xzvf $HOME/zabbix-2.0.0.tar.gz

cp $HOME/zabbix/bin/* /usr/bin

cp $HOME/zabbix/sbin/* /usr/sbin

groupadd zabbix

useradd -g zabbix zabbix

mkdir /var/log/zabbix-agent

chown zabbix:zabbix /var/log/zabbix-agent

nano /usr/local/etc/zabbix_agent.conf

Change "Server=127.0.0.1" option to the IP address of your Zabbix server, for example:

Server=192.168.1.10

Exit and save the file

nano /usr/local/etc/zabbix_agentd.conf

Change "LogFile=/tmp/zabbix_agentd.log" to:>/P>

LogFile=/var/log/zabbix_agentd.log

Change "Server=127.0.0.1" option to the IP address of your Zabbix server, for example:

Server=192.168.1.10

Change "ServerActive=127.0.0.1" option to the IP address of your Zabbix server, for example:

ServerActive=192.168.1.10

Rem out the "Hostname=Zabbix server" line:

#Hostname=Zabbix server

Exit and save the file

nano /etc/init.d/zabbix-agent

#! /bin/sh
  counter=0
  zabbix_counter=$(ps -ef | grep zabbix_agentd | grep -v grep | wc -l)
  
  start(){
  echo "-------------------------------------------------------------------"
  echo " LAUNCHING ZABBIX AGENT"
  
  if [ $zabbix_counter -gt 0 ]; then
  echo " * Zabbix agent was previously running"
  echo " * Number of Zabbix agentd instances= $zabbix_counter"
  echo "-----------------------------------------------------------------"
  fi
  
  # Checking if the user is able to start the agent.... if the user is not able to, script performs su to
  # the user zabbix and starts the agent
  
  if [ $(whoami) != "zabbix" ];then
  sudo -u zabbix zabbix_agentd
  else
  # Script is acting as the zabbix user, so it can start the agent.
  zabbix_agentd
  fi
  sleep 10
  
  zabbix_counter=$(ps -ef | grep zabbix_agentd | grep -v grep | wc -l)
  if [ $zabbix_counter -gt 0 ]; then
  echo " * Zabbix agent succesfully started"
  echo " * Number of zabbix agentd instances= $zabbix_counter"
  echo "-------------------------------------------------------------------"
  else
  echo " * Zabbix agent couldn't be started, check Zabbix logs"
  echo "-------------------------------------------------------------------"
  fi
  
  }
  
  stop(){
  # Checking if the user is able to stop the agent.... if the user is not able to, script performs su to
  # the user zabbix and kills the agent. Also script tries to kill zabbix-agent processes 5 times using a counter, if at
  # the fith try the agent is still there, script outputs a message to the console.
  
  echo "-------------------------------------------------------------------"
  echo " STOPPING ZABBIX AGENT"
  
  if [ $zabbix_counter -eq 0 ]; then
  echo " * Zabbix agent was not running on this machine"
  echo "-------------------------------------------------------------------"
  fi
  
  while [ $zabbix_counter -gt 0 ] && [ $counter -lt 5 ] ; do
  
  let counter=counter+1
  
  echo " * Number of Attempts (Max 5)=$counter"
  echo " * Stopping zabbix.."
  echo " * Number of zabbix agentd instances= $zabbix_counter"
  
  if [ $(whoami) != "zabbix" ];then
  sudo -u zabbix killall zabbix_agentd > /dev/null &
  else
  killall zabbix_agentd > /dev/null &
  fi
  
  sleep 10
  # Script has a 10 second delay to avoid attempting to kill a process that is still shutting down. If the script
  # can't kill the processes, an error will appear.
  # After 10 seconds script checks again the number of zabbix_agentd processes running,
  # if it's 0, script will exit the loop and continue on
  
  zabbix_counter=$(ps -ef | grep zabbix_agentd | grep -v grep | wc -l)
  
  done
  
  if [ $zabbix_counter -gt 0 ]; then
  echo " * Zabbix agent couldn't be stopped, check Zabbix logs"
  echo "-------------------------------------------------------------------"
  fi
  
  if [ $zabbix_counter -eq 0 ]; then
  echo " * Zabbix agent successfully stopped"
  echo "-------------------------------------------------------------------"
  fi
  
  }
  
  restart(){
  stop
  # Gives system some time to stop processes before script restarts service
  sleep 10
  # Now script can start the agent again
  start
  }
  
  case "$1" in
  start)
  start
  ;;
  stop)
  stop
  ;;
  restart)
  restart
  ;;
  *)
  echo "Usage: zabbix {start|stop|restart}"
  exit 1
  esac
  
  exit 0

Exit and save the file

chmod 744 /etc/ini.d/zabbix-agent

ln -s /etc/init.d/zabbix-agent /sbin/zabbix-agent

update-rc.d zabbix-agent defaults

Go to your Zabbix server's web interface and add the new system to hosts as you normally would and configure accordingly and you are done.

References:

http://www.zabbix.com/forum/showthread.php?p=103244#post103244

Enterprise Linux tools need packaging

With few exceptions (Puppet being one of them, because it just rocks) open source enterprise tools need to be packaged and available in one of the mainstream repositories (even EPEL is good enough! The bar isn't that high!) or your tool just isn't ready for primetime.

Looking at you Plone, LogAnalyzer, nxLog and LogStash! OSSEC gets a pass, but just barely because they are using the funky Atomic repo.

This is where tools like Zabbix and OSSIM come out ahead. The last thing you want to be doing when managing an enterprise, particularly in the industrial control space because of the funky requirements, is worrying about manually updating ANYTHING.

Really, the only reason why Puppet gets a pass is because it's so hugely useful in an enterprise.

And no, I don't want a bunch of excuses on why your tool isn't in a repository, whether it's for Debian, Ubuntu or the Red Hat side of things. If it's not available as a managed package, chances are your tool isn't going to be deployed by me or other IT people like me...and we tend to be a very stodgy group.

Linux would not have protected the Iranians against Stuxnet

Interesting discussion going on over at Google+ about the ramifications of Stuxnet and Flame. 

One part of the conversation is completely *facepalm*/smh (shaking my head) worthy, though. Someone brought up the extremely ludicrous notion that Linux would have protected the Iranians against Stuxnet and Flame. Linux totally would not have given the Iranians any extra protection.

The Stuxnet attacks are highly sophisticated and targeted and were able to get through every layer of the Iranian infrastructure to get embedded within the centrifuge controls. Flame, at least as far as I can tell, may have been used to provide the reconnaissance needed in order to build Stuxnet. It wouldn't have mattered what types of computers and OSes the Iranians used. The attackers would have just found vulnerabilities in any of them and developed exploits accordingly.

These hacks were very difficult to defend against and would have required a very thorough "defense in depth" strategy with a dedicated staff of security analysts to monitor and analyze network, OS and application logs and health. Even then, given the fact that spies were involved, It would have been an uphill battle to stop these attacks from succeeding.

There are certainly advantages that Linux gives to organizations within datacenters. Protecting them against highly advanced and targeted threats that exploit unknown weaknesses is not one of them, in my opinion.

Configuring iptables to log network traffic

For security as well as debugging purposes, it's a good idea to log the inbound, outbound, invalid and dropped packets that flow through the network interfaces on your linux systems. This is part one of a series with the rest, such as how to configure rsyslog.conf, to come later.

I was having problems getting iptables to log packets like I wanted, so I did some research on Google and found this post by Toast Research that detailed a good method for building your iptables modularly to allow for logging of packets.

Then I modified what they had done and came up with my own file and here it is. It is set up to allow port 80 through as well as ICMP pings, SSH connections, syslog messages and traffic from your Puppet server.

Just do 'nano /etc/sysconfig/iptables' when logged in as root (using 'sudo su -' of course) to modify your file to do what you want it to do.

The three digit numbers are there to allow for automated building of iptables files using DevOps systems like Puppet or Chef. The benefit to that is that you'd manage the iptables file at the enterprise level and these systems keep an audit trail of changes made and also ensure that systems stay properly configured. If someone were to change an iptables file managed by one of the DevOps systems, the DevOps system will revert to the proper file. That's the power of DevOps.

As you can see, the file is broken up into modules with the header defining what those modules are and the various rules either accept, log, drop or send packets further on down the chain.

# 001
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:invaliddrop - [0:0]
:loginaccept - [0:0]
:logoutaccept - [0:0]
:logdrop - [0:0]

# 002
# Accept all loopback connections
-A INPUT -i lo -j ACCEPT

# 003
# Forward all invalid packets to invaliddrop
-A INPUT -m state --state INVALID -j invaliddrop

# 004
# Forward all established connections to loginaccept
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j loginaccept

# 005
# Forward all icmp packets to loginaccept-A INPUT -p icmp -j loginaccept

# 006
# Forward these allowed input rules to loginaccept
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j loginaccept
-I INPUT -p tcp --dport 514 -s <your ip range here>/24 -j loginaccept
-I INPUT -p udp --dport 514 -s <your ip range here>/24 -j loginaccept
-I INPUT -p tcp --dport 8140 -s <your puppet server here> -j loginaccept
-I INPUT -p tcp --dport 61613 -s <your puppet server here> -j loginaccept

# 007
# Accept these rules without logging or forwarding them to loginaccept for logging
-I INPUT -m state --state NEW,ESTABLISHED -p tcp --dport 80 -j loginaccept

# 008
# Cleanup rule
-A INPUT -j logdrop

# 009
# Allow outbound loopback traffic
-A OUTPUT -o lo -j ACCEPT

# 010
# Forward all outbound traffic to logoutaccept
-A OUTPUT -j logoutaccept

# 011
# Drop all invalid packets (invaliddrop chain)
-A invaliddrop -j LOG --log-level 4 --log-prefix "IPTablesInvDrop: "
-A invaliddrop -j DROP

# 012
# Log accepted incoming packets at a rate of 2 per minute (loginaccept chain)
-A loginaccept -m limit --limit 2/min -j LOG --log-level 4 --log-prefix "IPTablesInAccept: "
-A loginaccept -j ACCEPT

# 013
# Log accepted outgoing packets at a rate of 6 per hour(logoutaccept chain)
-A logoutaccept -m limit --limit 6/hour -j LOG --log-level 4 --log-prefix "IPTABLESOutAccept: "
-A logoutaccept -j ACCEPT

# 014
# Drop all blocked packets (logdrop chain)
-A logdrop -j LOG --log-level 4 --log-prefix "IPTABLESDropped: "
-A logdrop -j DROP
COMMIT

Customize as needed.

Ever wanted to know how secure a Linux password file, with hashed passwords using SHA-512 and salt, is? I think this is a good answer: http://security.stackexchange.com/questions/4687/are-salted-sha-256-512-hashes-still-safe-if-the-hashes-and-their-salts-are-expos Pretty damn secure.

Problems sending OSSEC logs to rsyslog

Pulling OSSEC logs into syslog is really a mess. It doesn't format stuff at all how a syslog client would.

For instance, it buries the agent name in the message text instead of reporting it as the system name, which instead gets reported as the OSSEC server name that got the logs in the first place.

Plus it ranks everything as MEDIUM in syslog terms regardless of how they are ranked within the OSSEC logs.

So a priority 1 (very low) OSSEC event gets prioritized the same as a priority 10 (high) event.

This is all making me think that syslog just isn't all that great for use with log analysis tools in a heterogeneous environment.

Although it does seem possible to get rsyslog to change the way it handles certain kinds of logs...I'll have to do some digging to see if I can find instructions for doing this with OSSEC.

**Update: My friend Mike recommends http://www.ossec.net/doc/syntax/head_ossec_config.syslog_output.html?highlight=syslog#syslog_output for a possible solution.

Installing LogAnalyzer and rsyslog on CentOS

Instructions on how to set up Linux modules needed to get a LogAnalyzer log aggregation/analysis server up and running and collecting logs.

Prerequisites

These instructions are specific to CentOS 6.2. If you are using a different distro, many of the installation commands and paths to files will be different from what I've documented below. I strongly suggest that you document the steps to perform a similar install for your distro.

You will need to install the prerequisites by using the following commands:

yum install httpd
yum install mysql
yum install mysql-server
yum install php
yum install php-mysql
yum install php-gd
yum install rsyslog
yum install rsyslog-mysql
/usr/bin/updatedb 

The '/usr/bin/updatedb' command updates the file index so that the 'find' and 'locate' commands work properly. If you've already properly set up your system to index the files daily, this will be unnecessary.

If your distro of Linux is using a different syslog server such as syslog-ng or sysklogd, you'll need to remove it.

MySQL

Set up MySQL

/sbin/chkconfig --levels 235 mysqld on
/etc/init.d/mysqld start
/usr/bin/mysql_secure_installation

Hit enter key after last command has run since no password has yet been set for root MySQL account. Hit 'y' and enter when asked to set up a root password and type in a strong password. Hit 'y' and enter for the following questions: "Remove anonymous users?", "Disallow root login remotely?", "Remove test database and access to it?", and "Reload privilege tables now?"

Set up database and tables

Create the user/database/table and table schema:

Log in to mysql:

mysql -u root -p

Create a user:

CREATE USER rsyslog;
SET PASSWORD FOR rsyslog= PASSWORD('yourpasswordgoeshere');

Set up database and table schema:

CREATE DATABASE rsyslogdb;
USE rsyslogdb;

Paste contents below to mysql to set up the schema:

CREATE TABLE SystemEvents
(
 ID int unsigned not null auto_increment primary key,
 CustomerID bigint,
 ReceivedAt datetime NULL,
 DeviceReportedTime datetime NULL,
 Facility smallint NULL,
 Priority smallint NULL,
 FromHost varchar(60) NULL,
 Message text,
 NTSeverity int NULL,
 Importance int NULL,
 EventSource varchar(60),
 EventUser varchar(60) NULL,
 EventCategory int NULL,
 EventID int NULL,
 EventBinaryData text NULL,
 MaxAvailable int NULL,
 CurrUsage int NULL,
 MinUsage int NULL,
 MaxUsage int NULL,
 InfoUnitID int NULL ,
 SysLogTag varchar(60),
 EventLogType varchar(60),
 GenericFileName VarChar(60),
 SystemID int NULL
);
CREATE TABLE SystemEventsProperties
(
 ID int unsigned not null auto_increment primary key,
 SystemEventID int NULL ,
 ParamName varchar(255) NULL ,
 ParamValue text NULL
);

Next, we need to grant permissions to the rsyslog account we created earlier:

GRANT ALL PRIVILEGES ON `rsyslogdb`.* TO 'rsyslog'@'%' IDENTIFIED BY 'yourpasswordgoeshere';
flush privileges;

Leave MySQL:

exit

Configure rsyslog

Setting up

How to configure rsyslog:

nano /etc/rsyslog.conf

Make your #### Modules #### section the same as the following:

#### MODULES ####

$ModLoad ommysql        # provides support for MySQL
$ModLoad imuxsock.so    # provides support for local system logging (e.g. via logger command)
$ModLoad imklog.so      # provides kernel logging support (previously done by rklogd)
#$ModLoad immark.so     # provides --MARK-- message capability

# Provides UDP syslog reception
$ModLoad imudp.so
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp.so
$InputTCPServerRun 514

Just above ### begin forwarding rule ### section add info similar to the following line to limit IP addresses that can send syslog info to the server, for each class C subnet the server will be collecting from, you'll need to enter the subnet info followed by /24 (such as 172.18.22.0/24) to allow that subnet to send syslog data. Alternatively, you can limit by single IP addresses. The 127.0.0.1 is necessary so the server can send logs to itself:

$AllowedSender TCP, 127.0.0.1, 172.18.22.0/24
$AllowedSender UDP, 127.0.0.1, 172.18.22.0/24

Add the following line to the ### begin forwarding rule ### section. Replace the "<yourrsyslogpasswordhere>" bit with the password you set for rsyslog MySQL user above:

*.*       :ommysql:127.0.0.1,rsyslogdb,rsyslog,<yourrsyslogpasswordhere>

When done modifying the file, hit Ctrl+x, then y and then enter to save the file.

Restart the rsyslog service:

service rsyslog restart

Test rsyslog

Check if messages are arriving at the syslog server:

tail -f /var/log/messages

Check if messages are being stored in mysql database:

mysql -u root -p
use rsyslogdb;
select * from SystemEvents;

If you see anything other than “empty set” it’s working. Exit out of MySQL:

exit

Configure Apache

Configure CentOS to start the web server at bootup and manually start the service:

chkconfig --levels 235 httpd on
service httpd start

modify 2 lines to match your server's respective ip and fqdn in /etc/httpd/conf/httpd.conf

nano /etc/httpd/conf/httpd.conf
from:
Listen 80
to:
Listen ip.address.of.server:80
and from:
#ServerName www.example.com:80
to:
ServerName fully.qualified.domian.name:80

Hit CTRL+x, then Y and then enter to save and exit the file.

Restart the server:

/etc/init.d/httpd restart

Set up IPTables

Edit the iptables file:

nano /etc/sysconfig/iptables

Add these lines to the /etc/sysconfig/iptables file (before the COMMIT line):

-I INPUT -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
-I OUTPUT -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT

You'll need to enter lines similar to the following based on your network environment. For more info on how to use IPTables in CentOS see http://wiki.centos.org/HowTos/Network/IPTables:

-I INPUT -p tcp --dport 514 -s 172.18.22.0/24 -j ACCEPT
-I INPUT -p udp --dport 514 -s 172.18.22.0/24 -j ACCEPT

Restart the network service and IPTables:

/etc/init.d/network restart
/etc/init.d/iptables restart

Configure LogAnalyzer

Install LogAnalyzer

Check for the latest stable release by going to http://loganalyzer.adiscon.com/downloads in a browser. Current latest release is http://loganalyzer.adiscon.com/downloads/loganalyzer-3-4-2-v3-stable

Download it on your CentOS server by doing the following:

cd /tmp
wget http://download.adiscon.com/loganalyzer/loganalyzer-3.4.2.tar.gz

Uncompress the file:

tar -xvzf loganalyzer-3.4.2.tar.gz

Copy the source directory to the Apache html directory and create config.php file:

cd loganalyzer-3.4.2/src
rm -R -f /var/www/html
mkdir /var/www/html
cp -R * /var/www/html
cd /tmp/loganalyzer-3.4.2/contrib/
cp * /var/www/html
cd /var/www/html
chmod +x configure.sh secure.sh
./configure.sh

The last line will create a blank “config.php” file, and will give everyone write access to it. It won´t generate any output.

Check if the config.php file has been created (initial setup via browser will make changes to this file):

ls

Create LogAnalyzer MySQL user and database:

mysql -u root -p
create database loganalyzerdb;
CREATE USER loganalyzer;
SET PASSWORD FOR loganalyzer= PASSWORD('yourpasswordgoeshere');
GRANT ALL PRIVILEGES ON `loganalyzerdb`.* TO 'loganalyzer'@'%' IDENTIFIED BY 'yourpasswordgoeshere';
flush privileges;
exit

Initial setup of Log Analyzer, Step One:

On a client system go to the Log server's URL using a web browser (http://yoursystemnamehere.blah.org).

A message stating "Critical Error Occurred: Error main configuration file is missing! Click here to install Adiscon LogAnalyzer!" will appear in browser. Click on the word "here" to start the install.

Click "Next" twice and you should get to the "Basic Configuration" screen. The recommend settings are:

• Number of syslog messages per page: 200 (set this lower if the log server is on a slow system)
• Message character limit for main view: 80 (default)
• Character display limit for all string fields: 80
• Show message details popup: Yes (default)
• Automatically resolved IP Addresses (inline): Yes (default)
• Enable User Database: Yes
• Database Host: localhost (default)
• Database Port: 3306 (default)
• Database Name: loganalyzerdb
• Table prefix: logcon_
• Database User: loganalyzer
• Database Password: <enter in the loganalyzer database user password that you set earlier here>
• Require user to be logged in: Yes

Click "Next".

Initial setup of Log Analyzer, Step Two:

Click "Next" on the "Create Tables" page, then click "Next" on the "Check SQL Results" page and then set up the admin user:

• Username: <enter in the username here that you want>
• Password: <enter in the user password that you want to use>
• Repeat Password: <re-enter in the user password that you want to use>

Click "Next".

Initial setup of Log Analyzer, Step Three:

The recommended settings for the "Create the first source for syslog messages" page are:

• Name of the source: All Syslog Sources
• Source type: MySQL Native
• Select view: Syslog Fields (default)
• Table type: MonitorWare
• Database host: localhost (default)
• Database name: rsyslogdb
• Database table name: SystemEvents
• Database user: rsyslog
• Database password: <enter in the rsyslog database user password that you set earlier here>
• Enable row counting: "Yes"

Click "Next" and then click "Finish".

The install of LogAnalyzer has now been completed. Now other users can be created and there are many settings that can be tweaked as needed.

Point all of the syslog capable devices to the new log server and begin analyzing the aggregated logs.

References

The following sites were used to help figure this all out

http://en.tiagomarques.info/2011/07/centos-syslog-server-rsyslog-mysql-and-loganalyzer/

http://www.pantz.org/software/mysql/mysqlcommands.html

http://pkgs.fedoraproject.org/repo/pkgs/phplogcon/README.fedora/5aa1ea186764ba0a7ea239131141734a/README.fedora

http://www.linuxhelp.in/2010/10/how-to-configure-syslog-server-or.html

http://www.beguelin.com/2009/05/locate-and-updatedb-on-centos.html

Chris Borte's brain