Basic Audit (Re-)Viewing in Spacewalk

Introduction

Government regulations require that regular audits are performed on their computer systems.  Other government auditors regularly verify that these audits are performed.  This is where the Linux auditing system comes in.  It is used to meet these requirements and can provide a wealth of information about a running Linux system.  Syscalls, user logins and ends, configuration changes in the audit system, SELinux denials, the addition or removal of users/groups, and more can be monitored.

Linux and the Brother HL-2270DW printer: success!

This printer was remarkably easy to setup under Linux.  It was something of an impulse buy after my inkjet ran out of ink... and after I clicked "Checkout" I thought to check what Google had to say about the support for Linux.  There were no great success stories, so I thought I would have to fight with it for a few weeks to get it to a decent state...  Surprise!  It took only a few hours, of which most were me exploring the device.

I setup the printer on the network using ethernet (the wireless is nice, if I need it later... but for now it's sitting next to the router, so...) and for sanity I set it to get the same dhcp leased IP address (the lazy man's static).  The Printers dialog in Fedora 14 quickly discovered the printer after I opened the Network arrow, which was really cool.  I found out, via Wireshark, that it has some kind of webservice broadcast thing as well as a SNMP method of discovery... oh, and netbios.  There's probably a few I'm missing...  oh yes, dns-sd/avahi and LLMNR... anyway, the network support built-in to this printer really impressed me.

I actually ended up selecting IPP printers and entering the URI manually rather than choosing the automatically discovered one, which had a URI like: dnssd://Brother%20HL-2270DW%20series._ipp._tcp.local/  Entering it manually seemed to give me a few more options and even detected the toner level (well, kind of- I think the "starter" cartridge screws it up... we'll see after I print my way through it).  The URI I used was: ipp://$IP/pcl_p1 and the driver I chose was "Generic PCL Laser Printer" with the Duplex option checked.  And it's worked perfectly since then!!  How awesome is that.  I didn't even have to install any of the semi-GPLv2 software from Brother.

In short, I would recommend this printer to anyone that's looking for a full-featured (black/white and single-function) and yet not way too expensive laser printer.  Especially if you can find it on sale for $79.99 like I did :-)

Update 16 Aug 2012: load nf_conntrack_snmp to auto-detect the printer in Gnome 3's printer dialog.
# echo "install nf_conntrack_snmp" > /etc/modprobe.d/brother_hl2270dw.conf

update your xbee firmware under linux!

I just got a pair of xbee radios from Digi (http://www.digi.com/xbee/) last week, as I begin my hobby of embedded electronics, and they're very cool.  I already have a ton of ideas that, given time and money, I want to work on.  The only thing that bothered me was that there was no firmware update utility for Linux.  Well, no more!  The datasheet from Digi had the details of how to enter the bootloader and upload firmware to the xbee, and I spent the past few nights learning about serial communication and programming.  The result is a small utility that can upload new firmware images to your xbee!

As of now, there are a couple of caveats (that will all eventually be fixed):

• the device is hard-coded as /dev/ttyUSB0
• you can only program an xbee currently in AT mode (you can go to API mode fine, but my utility doesn't speak API yet)
• need to handle radios in strange states or non-default baud rates, etc.

I only have 2 radios to test on, so: FLASH AT YOUR OWN RISK!  This works for me, but I'm sure that there will be situations and hardware that this will not work on (for now).  That aside, the xbee bootloader seems fairly robust, and when I accidentally re-programmed the same block several hundred times, it was able to recover.

I'll edit this later after I find a place to put my code...
Edit: https://github.com/roysjosh/xbee-comm

And now, the text equivalent of a screenshot!

$ time { ./xbfwup 2270/ebl_files/XB24-ZB_2270.ebl ; }
Read 100608 byte firmware file (786 blocks).
................................................... 50
.................................................. 100
.................................................. 150
.................................................. 200
.................................................. 250
.................................................. 300
.................................................. 350
.................................................. 400
.................................................. 450
.................................................. 500
.................................................. 550
.................................................. 600
.................................................. 650
.................................................. 700
.................................................. 750
...................................
Programming complete, running uploaded firmware...

real    0m25.392s
user    0m0.023s
sys     0m0.042s

firefox, x509, Subject CN, and subjectAltNames

Note to self: firefox will ignore the Subject CN if you have a DNS subjectAltName in your certificate.  Sigh.  /me revokes and regenerates certificates...

order is important: memset, thunderbird 3.0.1

A few minutes ago, I heard that Thunderbird 3.0.1 can cause email corruption, which alarmed me, because that's what I am currently running.  I investigated, and noticed that in the patch the root issue was an incorrect usage of memset...  Specifically, the "size_t n[umber]" parameter, which indicates how many bytes to write, was swapped with the "int c[onstant]" parameter, indicating the byte to write.  Luckily for most of these "backwards" errors, the fill-byte constant is a 0, so when it is placed in the "number of bytes to write" position, it doesn't matter that there is now a "random" number in the fill-byte constant.  Unfortunately, you then end up using uninitialized (or old) data, like in this case with TB3.  A google codesearch reveals just how often this problem occurs...

jwhois-4.0 and 100% CPU usage on whois lookups

A few months ago I started to notice that every now and then a whois lookup would eat one of my CPUs. Running whois under strace quickly revealed something interesting:

converting zmud maps to tintin++, and tintin++ with 100k rooms

The past few days I've been examining the telnet clients available for linux. There isn't too much to speak of, unfortunately. Many of them aren't under active development. However, I found a new MUD client being developed called mudlet that has the potential to be pretty cool.

I ended up using tintin++, since it had a rudimentary auto-mapper which looked interesting. After playing around with it for a while, I wondered if there was a way I could use my zmud maps with tintin++. I couldn't find my wotmud maps from a long time ago, so I grabbed the ones available from map.wotmad.org. What follows is the rough steps it took to get them into a format tintin++ understood.

1. export zmud MDB data
2. regex it into something sqlite likes
3. throw it at sqlite
4. tweak some data so tintin++ can do more things (like colors) faster/easier
   
5. grab what we need from sqlite and output tintin++'s format

What you need:

• mdbtools
• sqlite3
• DBD::SQLite
• mdb2sqlite.pl
• zmudconv.pl

And of course a zmud mdb file. And now...

$ perl ./mdb2sqlite.pl zmud.mdb
...
$ perl ./zmudconv.pl zmud.mdb.sqlite > tintin.map

mdb2sqlite.pl throws some errors on MetaTbl and another at the end, but they seem to be harmless. If you have a suggestion for a fix, I happily accept patches (or just guru-like advice too, I suppose).

Also, a few more things. My wotmud map had too many rooms for tintin++, so I wrote a little patch that increases the maximum (to 100k) to fix that. It seems to work for me, but YMMV.

Finally, for those of you using a distro without tintin++, but with RPM, here's a specfile for you (that uses the above patch, too). Just pull the patch into SOURCES/ first.

$ rpmbuild --sign -ba SPECS/tintin.spec

* Without the --sign if you don't have rpm set up to use gpg.

Anyway, happy MUDding!