Today I needed to allow users in a group to execute an X app (virtualbox in this instance) as a single user. sudo to the rescue … So after updating /etc/sudoers (via Puppet), to keep the env variables and allow the members of the group to run virtualbox. Defaults env_keep += “DISPLAY XAUTHORIZATION XAUTHORITY”

1
2
3
4

  $ sudo -E -u commonuser /usr/bin/xcalc 
  mike's password:
  X11 connection rejected because of wrong authentication.
  Error: Can't open display: localhost:15.0

hmm, xauth has struck …a tweak on the oneliner from Jason Howk, and we’re nearly there. it isn’t quite enough, we also need to allow the common user access to our X DISPLAY.

So the final solution is a short script (Usage: sudo_x.sh target-user X-app):

1
2
3
4

#!/bin/sh
xhost +$1
xauth extract - :`echo $DISPLAY |awk -F: '{print $2}'` | sudo -u $1 /usr/bin/xauth merge -
sudo -E -u $1 $2

I’ve just been updating and testing my Puppet deployment script on openSuSE 11.4., and found that a some updates to the script are required to support openSuSE 11.4.

I also start my builds from the Minimal Install pattern, this pattern doesn’t include lsb or dmidecode. dmidecode has previously included, and appears to have been dropped for some reason. The lack of dmidecode means that some of the facts reported by Facter such as Manufacturer, serialnumber, and productname weren’t reported. I use the fact serialnumber as the base for the Puppet certname on clients that use DHCP. This was easily fixed by adding the installation of the dmidecode package to my script.

Lsb-release, on the other hand hasn’t never been included in the Minimal Install pattern, but it depends on /usr/bin/lp which conflicts with the cups-client package which ships by default in the Minimal Installation pattern. Consequentially this requires manual intervention, so I’ll need to find a mechanism to automate the inclusion of lsb as I use the lsb facts in my Puppet recipes.

Update, the lsb package has been dropped, but lsb-release is still available.

1
2
3
4
5
6
7
8
9
10
11
12

# zypper install lsb
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: lsb-4.0-12.1.x86_64 requires /usr/bin/lp, but this requirement cannot be provided
  uninstallable providers: cups-client-1.4.6-6.1.x86_64[openSUSE-11.4-11.4-0]
                   cups-client-1.4.6-6.1.i586[repo-oss]
                   cups-client-1.4.6-6.1.x86_64[repo-oss]
 Solution 1: deinstallation of patterns-openSUSE-minimal_base-11.4-6.9.1.x86_64
 Solution 2: do not install lsb-4.0-12.1.x86_64
 Solution 3: break lsb by ignoring some of its dependencies

I’m currently working on restructuring an organizations infrastructure to being managed and driven through Puppet. Hopefully I will be able to share some of the modules that I have been working on. These modules cover:

• ClearCase
• Hudson
• RT
• Codestriker
• Trac

and a range of other more general infrastructure services.

Well its been a while, but I’ve made a number of significant updates to LogParse recently.

I’ve updated my logparse.pl script again (http://github.com/mikeknox/LogParse). This release (v0.4/STABLE) includes a number of significant changes.

The major ones are:

1. Specify the logfile format in the config file
2. Multiple log and config files specified on command line
3. Multiple actions & reports for each rule
4. The arithmetic reporting functions have been moved from ACTION’s to REPORT’s.

These changes actually make it more portable and allow differing reports to be easily generated from the same data set.

For example, here’s part of last night’s report for one of my webservers …

Invalid ssh login attempts by source host
1259 invalid user login attempts from 116.126.87.162 on sysam
128 invalid user login attempts from 88.87.85.3 on sysam
40 invalid user login attempts from 200.195.127.215 on sysam
96 invalid user login attempts from 67.225.232.40 on sysam
1 invalid user login attempts from 83.222.125.171 on sysam
6 invalid user login attempts from 62.112.195.219 on sysam
128 invalid user login attempts from 204.16.179.50 on sysam
1 invalid user login attempts from 208.71.174.96 on sysam
2788 invalid user login attempts from 59.41.39.117 on sysam
4 invalid user login attempts from 119.161.145.162 on sysam

Invalid ssh login attempts by target
4451 invalid user login attempts on sysam

The rule used to collect and report this data in the config file is:

1
2
3
4
5
6
7
8

RULE sshd {
  APP sshd
  MSG /^Invalid user/
  ACTION MSG /^Invalid user (.*) from (.*)$/ {HOST, 1, 2}
  # REPORT "Invalid ssh login attempts by user & source host" "{x} ssh invalid user login attempts by {2} from {3} on {1}" count
  REPORT "Invalid ssh login attempts by source host" "{x} invalid user login attempts from {3} on {1}" count
  REPORT "Invalid ssh login attempts by target" "{x} invalid user login attempts on {1}"
}

As you see from the commented out report entry, I could include all the invalid account names which they attempted to access, but I felt this wasn’t useful information for me in this report.

I was looking for some updated references on Solaris (particularl yOpenSolaris), and I came across this posting in the Switzerland OpenSolaris User Group’s wiki … http://wikis.sun.com/display/chosug/Solaris+Books It’s got a nice set of links to Solaris/OpenSolaris documentation PDF’s as well as a number paper texts (@ amazon.com)

There’s also Joerg Moellenkamp’s ‘The consolidated “Less known Solaris Features” tutorials’ at c0t0d0s0.org.

While deploying LogParse on a new server, I need to update a some of the rules. As part of updating the rules, I found that we needed a bit more flexibility in how the matching parameters in the rule stanza. So you can now have multiple entries in the MSG, HOST, FACILITY and APP expressions and all of the expressions are applied.

I added it so I could have a simplier method matching complicated MSGS. eg MSG /abc/ MSG /!def/ This will then match rules that contain “abc” and do not contain “def”.

In doing this I fixed a bug which would have stopped a negate rule being applied on the first parse of a line.

The code in the GitHub repository for LogParse now has the update and fix.

I plan on adding the ability to specify multiple config files on the command line. This would then allow you to use a generic logfile and a seperate site specific rule file.

Monitoring the logs is a core task in keeping computer systems running smoothly, whether it’s 1, 10 , 100’s or 1000’s of systems. This is referred to as syslog in Unix systems, and events in Windows systems.

It enables monitoring of system trends, warnings, and monitoring of other interesting data that may not be picked up by your monitoring system. It provides another level in your monitoring arsenal. It also provides a mechanism for correlating events that occurred at different places in the system to determine a root cause for problems.

One of the early changes I made at Preston Aviation Solutions was to implement centralised logging of the Unix systems (syslog) and then running them through a perl script which I had developed (LogParse) previously. This enabled the admin team to review a sanitised view of the consolidated logs at the start of their day (emailed to them).

Now however there are a range of other tools and product that do a really good job of analysis.

These days I would look at Splunk to consolidate and report on logs and events.

A couple of other tools or links to look at are:

• SEC (Simple Event Correlator)
• Syslog wiki