Charles Mauch posted a very neat set of xmodmap files and a nifty trick for switching between dvorak and qwerty while at the gdm login menu.

The following is a rehash of his switching-to-dvorak blog post, archived here for my own future personal reference.

First, you need to download xmodmap.kludge, and xmodmap files for dvorak and qwerty. Then add these two lines to your .bash aliases (or equivalent: .bash_login, .profile, etc)

alias aoeu='xmodmap_kludge ~/.xmodmap.qwerty | xmodmap -'
alias asdf='xmodmap_kludge ~/.xmodmap.dvorak | xmodmap -'

Now at a terminal, simply typing asdf will swap layouts to dvorak, and striking the same keys in order in dvorak will switch back to qwerty.

His other trick is to add the following lines to your xorg.conf to swap layouts in X by holding down both shift keys at the same time.

Section "InputDevice"
Identifier      "Generic Keyboard"
Driver          "kbd"
Option          "CoreKeyboard"
Option          "XkbRules"      "xorg"
Option          "XkbModel"      "logielite"
Option          "XkbLayout"     "us,dvorak"
Option          "XkbOptions"    "grp:shift_toggle"
EndSection

The important lines to notice are the last two. Both layouts are loaded by X, and it’s toggled with shift keys.

Slick.

Lelik P. Korchagin has written vblade-kernel, an AoE target emulator implemented as a kernel module for Linux 2.6.* kernels.

It is reportedly much faster than the user-mode vblade implementation. I'm playing with it now.

I've built a set of CME-681 rules to catch the common 6 english messages:

cme-681.cf

This particular Sober worm is also known as:

• CA: Win32.Sober.W
• F-Secure: Sober.Y
• Kaspersky: Email-Worm.Win32.Sober.y
• McAfee: W32/Sober@MM!M681
• Norman: W32/Sober.AA@mm
• Panda: W32/Sober.AH.worm
• CommandAV/Sophos: W32/Sober-Z
• Symantec: W32.Sober.X@mm
• TrendMicro: WORM_SOBER.AG
• ClamAV: Sober.U

If you have a VoIP phone service, like Vonage, you can use tcpdump to capture entire phone conversations that can later be reassembled using only ethereal, rtptools, and Quicktime.

You should be able to do this on a PC using the Windows version of Quicktime player and cygwin or native ports of ethereal and rtptools.

The following steps are for a Mac:

Step 1: Record the phone conversation

Before you start your phone conversation, start the following on your network firewall, or any node that can capture both sent and received traffic from your VoIP device:

# tcpdump -i eth0 -s 1500 -n -w voip.pcap

This will create a file called "voip.pcap" containing all packets sent and received. Leave this running until your call is finished, then cntl-c out of it.

Sure, you can make this much more complicated, or even use other capture tools that output pcap packet capture dumps (like ethereal), but this demonstration is trying to stay as simple as possible for typical firewalls and hosts.

Step 2: Install some required software

To parse through the voip.pcap file and save each half of the conversation (both RTP streams), we will use ethereal.

Before attempting the ethereal install, you will want to install the Apple OS/X Xcode dev environment and the Apple X11.app and Apple X11 SDK. Ethereal is not a carbon app.

To install ethereal quickly and easily, I recommend installing Darwin Ports and use a simple:

# port install ethereal

If you use Fink, you should be able to install it this way:

# apt-get install ethereal
or
# fink install ethereal

The other piece you will need is rtptools. Building it should be as simple as:

# cd /usr/local/src
# curl -o rtptools.tar.gz http://www.cs.columbia.edu/IRT/software/rtptools/download/rtptools-1.18.tar.gz
# tar xvzf rtptools-1.18.tar.gz
# cd rtptools-1.18
# ./configure
# make install

You will also want to download and install something like Ambrosia Software's WireTap Pro to record your audio while you're playing it back.

Step 3: Prepare rtpdump files with ethereal

We're really only using ethereal to filter the tcpdump into component packet capture dumps for each stream.

So, fire up ethereal:

$ export DISPLAY=:0.0
$ ethereal

When ethereal appears, open the "voip.pcap" file. This will open up an Analyze panel with the packet dump.

From the menu bar, select "Statistics". From that Statistics dropdown menu, select "RTP". From the RTP submenu, select "Show all Streams".

A stream selection dialog will appear. There will be a source IP and port and a destination IP and port.

Select the first stream. Look at the destination port number (say port 13456). Now click "Save as". Give this stream a filename that references the destination port number (like "voip-13456.pcap").

Select the second stream. Look at the destination port number (say port 12345). Now click "Save as". Give this stream a filename that references the destination port number (like "voip-12345.pcap").

You are now done with Ethereal.

Step 4: Create an SDP file for Quicktime, and start it up

Noting the above destination ports for each stream, we want to create an SDP file for Quicktime telling it what ports to start playing:

Open up Textedit (or vi, or just cat the following to a file):

v=0
o=icblenke 2890844526 2890842807 IN IP4 127.0.0.1
s=SDPTest
i=SDP file for G711 audio on port 10128
c=IN IP4 127.0.0.1
t=0
m=audio 12345 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
m=audio 13456 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

This defines two 64k G.711 audio streams on UDP ports 12345 and 13456 (one for each side of the conversation). You will want to change these port numbers with the destination port numbers for your streams.

Yes, Quicktime will play more than one audio stream at a time. No, the other fields really aren't all that important (my name, those extra numbers, the IP, etc).

Now "Open File" the SDP file within Quicktime. Quicktime will report "Connecting", which means that it is waiting for the streams from the step after next.

Step 4: Start WireTap Pro

Be prepared to start the rtpplay commands in the next step shortly after opening WireTap Pro and clicking the record button. You can always edit the recorded AIFF audio later to strip out any captured silence.

Step 5: Fire up rtpplay on the streams

You will need to open up two Terminal windows for this next step, or otherwise stack these so they start at the same time:

$ rtpplay -T -f voip-12345.rtp 127.0.0.1/12345
and
$ rtpplay -T -f voip-13456.rtp 127.0.0.1/13456

Your Quicktime will begin immediately playing the streams. You should hear both sides of the conversation.

Step 6: Stop WireTap Pro and transcode with iTunes

Once the rtpplay streams finish playing, you merely need to stop recording with WireTap Pro. WireTap Pro will prompt you for a filename. The file will be saved in an AIFC (AIFF compressed) format.

After saving, open the AIFC file by double-clicking on it.

Alternatively, Open "Applications > iTunes" (in the Finder, open the folder where you saved your aiff file and move your windows around so you can see the folder and iTunes). Drag your aiff file into iTunes.

Find the AIFC file. Depending on the size of your iTunes repository, you might just want to use the Search function and type in the filename.

With the AIFC file selected, select "Advanced > Convert Selection to AAC" (or MP3 if you have that in your iTunes->Preferences->Advanced->Import settings). iTunes will show a temporary playlist that reads "Converting Songs..." while it encodes the audio.

You now have an AAC or MP3 audio clip of your VoIP conversation.

Enjoy.

This was originally posted by Martin Regner on the ethereal-users mailing list. The above is merely my experience with this quick and dirty technique.

Xen 3.0 was released on 12/05/2005

It has initial support for unmodified guests when using Intel VT hardware (Intel's Vanderpool or AMD's Pacifica) like the new 3.6 GHz Pentium 4 662 and 3.8 GHz Pentium 4 672, or newer higher-end dual core Xeon Paxville 7000 series chips.

This would allow you to run Windows, unmodified, under Xen.

VMWare will soon be supporting the VT features as well

Unfortunately, you're not going to see a BIOS that supports enabling VT until early 2006 - everything done to date on this has apparently been in Intel labs. They haven't released a way to enable this in hardware quite yet.

Until you can get your hands on VTX hardware, however, you can still run Windows under Win4Lin Pro or QEMU without kqemu/qvm86. Without a kernel module helper to run ring0 virtualized, however, you're dealing with dead slow emulation.

At least one project has appeared recently to provide something like the as-yet unreleased XenOptimizer frontend for Xen: Enomalism. Looks oddly like the VMWare MUI doesn't it?

Luke Kanies mentioned that someone pointed him toward Freeride's Freebase "bus".

Looking into it, it's a neat programming model, though the bus doesn't seem to address transport issues or be intended to run across more than one machine. For that matter, it doesn't appear Freebase persists queues at all between restarts. It has a neat plugin architecture though allowing for easy extensions, and the Slot abstraction is a good idea.

Documentation is sparse though, reading the code is the best way to grok it.

As a reliable transport for messages on a system, I'm still most interested in Assaf Arkin's reliable-msg library.

Using Freebase with a Slot handler for a reliable-msg Queue would be neat though. I'm digging through Freebase and reliable-msg now to see if I can devise something.

Yes, this is getting into implementation rather quickly. So many alternatives and variables.

The idea is to get something going, to keep up the momentum. Release early, release often...

An extension of the DARPA UltraLog project, the Cougaar agent architecture appears to be a message bus based system.

The ACME framework is a ruby based control and test platform for Cougaar, so it's not Java centric.

It looks like Cougaar was the outcome of the DARPA UltraLog project for distributed agent development.

Q. Which Message Transport protocols are supported?
A. The Cougaar architecutre includes a Message Transport with pluggable "Link Protocols". The standard protocols are:
   - Lookback in-memory tranport (for intra-node traffic)
   - RMI
   - SSL-encrypted RMI
   - CORBA
   - HTTP
   - SOAP

Protocols include plain TCP Sockets, UDP, SMTP, and NNTP. Third-party developers can write new link protocols and plug them into Cougaar.

There has been much discussion on the SAGE config-mgmt list regarding Luke Kanies' effort toward a message bus for Puppet.

A number of folks in #puppet on irc.projects.net continue to talk about this new message bus and what it should accomplish.

The goals are:

1. Create a message router that will allow agents to subscribe to message feeds
2. Write agents for each subsystem or opensource component engine that either publish or subscribe to those messages.

These messages may range from simple syslog messages and SNMP traps to system stats, IDS alerts, netflow log snippets, or anything else that might concern a sysadmin.

The Runnel message bus needs two things:

1. A data abstraction for the messages
2. A transport to ship them around reliably.

For data abstraction, the primary contenders are RDF and microformats. Luke posted to the microformats list asking for their input on this matter.

For transport, we would like to keep it simple yet allow for the messages to be transported over any network topology. This might be as simple as messages transported over SMTP to messages sent over a direct TCP socket connection between an agent and the router.

The goal is not to make a message bus that will solve any computing problem generically. We're not trying to rework MQSeries here. In the end, this will solve a problem for Puppet, and potentially open up an avenue for communication between disparate systems like Request Tracker (RT), Nagios, SEC, and any other subsystems we can build agents to communicate over the bus.