Giganews header compression posted Tue, 25 May 2010 02:22:38 -0500

by nipsy permalink

After messing around a bit with TCL, I finally figured out how to read the compressed headers from Giganews. Yay.

Thanks to a post over here, I was able to start with the basic NNTP conversation and add the rest I pieced together over the past couple of nights. My version with compression and SSL looks like this:


#!/usr/bin/tclsh

# load tls package
package require tls

# configure socket
set sock [tls::socket news.giganews.com 563]
fconfigure $sock -encoding binary -translation crlf -buffering none

# authenticate to GN
puts stderr [gets $sock]
puts stderr "sending user name"
puts $sock "authinfo user xxxxxxxx"
puts stderr [gets $sock]
puts stderr "sending password"
puts $sock "authinfo pass yyyyyyyy"
puts stderr [gets $sock]

# enable compression
puts stderr "sending xfeature command"
puts $sock "xfeature compress gzip"
puts stderr [gets $sock]

# set group
puts stderr "sending group command"
puts $sock "group giganews.announce"
puts stderr [gets $sock]

# issue xover command based on group posts
puts stderr "sending xover command"
puts $sock "xover 2-48"
set resp [gets $sock]
puts stderr $resp

# if the response is 224, parse the results
if {[lindex [split $resp] 0] == "224"} {

# loop through uncompressed results
#       while {[gets $sock resp] > 0} {
#               if {$resp == "."} {
#                       puts stdout $resp
#                       break
#               }
#               puts stdout $resp
#       }

# loop through compressed results
        while {[gets $sock resp] > 0} {
                if {[string index $resp end] == "."} {
                        append buf [string range $resp 0 end-1]
                        break
                }
                append buf $resp
        }
}

# uncompress those headers!
puts -nonewline stdout [zlib decompress $buf]

# issue a quit command
puts stderr "sending quit"
puts $sock quit
puts -nonewline stderr [read $sock]

Feel free to take the results and run. I'm not sure if there is a limit to how many headers you can fetch in a single go. I imagine it's more or less limited to your local buffer size, so don't grab too many at a time (at least in TCL I imagine). Anything more aggressive would require some fine tuning no doubt. But this was all just proof of concept to see if I could make it work. Now to write my newzbin.com replacement!

fceux and multitap fun posted Sat, 16 Jan 2010 14:26:09 -0600

by nipsy permalink

I've been trying to get four player support in fceux working. I finally broke down sometime ago and wrote a couple of the programmers working on the project. It seems the SDL port of the game had missed a core change somewhere along the way to maintain working multitap support.

But after a quick look at the code apparently, one of the programmers got things back in working order, and now things like Gauntlet 2 and Super Off-road can be played in all their four player glory!

The mysterious option to use is fceux -fourscore 1 game.nes.

Along the same time, I discovered an undocumented nastiness. If you're foolish enough to change some of the options via the command line, specifically the --input1 gamepad option for example (which I'm fairly certain worked in some previous incarnation of fceu(x), you will wonder why suddenly all of your controls have stopped working. Looking at the generated fceux.cfg, those options should now be --input1 GamePad.0 for example. Use 1-3 for the others. If you just leave things alone though, this will be the default.

avoiding potential online fraud posted Tue, 12 Jan 2010 19:46:39 -0600

by nipsy permalink

So I am looking at buying this spiffy new gadget, a Roku SoundBridge. I found someone wanting to get rid of a couple used ones for a reasonable price. The problem is, he replies telling me he doesn't accept PayPal, but cash or a money order will suffice. Wait, what!? Of course, he also assures me he's a reputable person and I can verify this by checking some other online forum where he apparently engages in some kind of online commerce. Well great.

In case you haven't already run into this before, this should be an immediate warning sign! I would think by 2010, everyone would understand the ins and outs of Internet commerce and both buyers and sellers would have the self awareness to educate themselves otherwise. Apparently not.

It's all a simple matter of trust. Do I know this person? Hell no. Should I trust this person to any measurable degree? Well, ideally yes. But it's an imperfect world full of people with varying values. Regardless of whether I think people should commit fraud, the fact of the matter is they do, every moment of every day. I'd love to accept the idea that people are generally honest and that everything will turn out just fine. But having been around the blocks a few times myself, I cannot.

So I do a little digging myself for online systems to safely manage online transactions. There is of course the aforementioned PayPal. It is not alone in its space, but I think it's safe to say, certainly the most recognized.

C.O.D.'s also came to mind. But apparently regardless of the carrier (USPS, UPS, FedEx), C.O.D.'s are absolutely useless and will most likely get you a whole lot of nothing as someone trying to sell an item for cash. There is a LOT of fraud happening in the C.O.D. world, so it's probably best to avoid it entirely.

And finally, there are the online escrow services. Escrow.com seems like a good place to start for such things. I did a little more digging to verify they were in fact a reputable entity, and as it turns out, such entities are fairly well regulated. In this particular case, you can check a governmental web site in California to verify they are a legitimate business and licensed by the state to conduct business as an escrow service. In my particular case, the minimum fee of $25 seems a little much since it's a significant percentage of the actual cost of the items. But it's well worth it if nothing else can be agreed upon.

So anyway, I hope someone eventually finds their way here, and any of this information proves useful. There are probably countless other businesses which provide similar services, but please make sure you try to verify the company is legitimate. Don't just accept that Better Business Bureau logo at the bottom of the very company's page of which you're trying to establish legitimacy. At the very least, don't send an unmarked wad of cash to someone you don't know. Seems like that goes without saying. But as David Hannum (not P. T. Barnum) said, "There's a sucker born every minute."

publishing real SPF resource records with tinydns posted Tue, 12 Jan 2010 19:45:36 -0600

by nipsy permalink

Since I just suffered a bit trying to figure this out on my own, I figured I'd blog about it so no one else would have to suffer. I was snooping around earlier looking at my exim configuration and messing with my current SPF records. Because of the handy SPF tool here, I learned that there is now a dedicated SPF resource record (there has been for awhile apparently as defined in RFC 4408).

So being who I am, I immediately set out to discover how to publish such a record via tinydns, my chosen DNS server software.

Since the stock version of tinydns doesn't support the SPF record type directly, you're left using the generic declaration. My current TXT record for bitgnome.net is:


'bitgnome.net:v=spf1 a mx a\072arrakis.bitgnome.net -all:86400

The proper form of this as an actual SPF resource record in the generic tinydns format becomes:


:bitgnome.net:99:\047v=spf1 a mx a\072arrakis.bitgnome.net -all:86400

Now, if you're at all familiar with SPF records in general, the \072 will probably make sense as the octal code for a colon. The tricky part that had me confused was the \047 which happens to be an apostrophe. Using a command like dnsq txt bitgnome.net ns.bitgnome.net gave me a TXT record with the expected SPF string as a return, but prepended by a single apostrophe.

Once I finally realized that it was giving me the length of the record in bytes in octal (\047, or 39 bytes for this particular record), everything finally clicked! I initially tried prepending my other domains with the exact same value and kept wondering why host -t spf bitgnome.com was returning ;; Warning: Message parser reports malformed message packet.!

So simply convert the SPF record length (everything from v= to the end of the string (-all in my case)) in bytes from decimal to octal, slap it on the front of that generic record definition, and away you go!

progress, progress, and more progress posted Tue, 12 Jan 2010 17:14:02 -0600

by nipsy permalink

I've been banging my head against a few walls lately, all related to the inevitable, yet sometimes annoying march of progress.

The first problem to rear its ugly head was based on a somewhat recent change in the netbase package of Debian. Specifically, the sysctl net.ipv6.bindv6only was finally enabled to bring Debian up to snuff in relation to most other modern operating systems. This is all well and good, since IPv6 is fairly solid at this point I imagine. The problem is, a few outlying programs weren't quite prepared for the change. In my case, several Java interpreters (Sun and OpenJDK, or sun-java6-jre and openjdk-6-jre in Debian) and murmurd from the Mumble project (mumble-server in Debian).

I reported the murmurd problem on both SourceForge and the Debian bug tracker. The problem had actually already been fixed by the developers, it just hadn't made it into a release yet. That was all fixed though with Mumble 1.2.1. Along the way, I learned a lot more about IPV6_V6ONLY and RFC 3493 than I ever wanted.

Java required a workaround, since things haven't been fixed yet on any release for the Sun or OpenJDK interpreters. All that was needed was -Djava.net.preferIPv4Stack=true added to my command line and voila, everything is happy again.

The other serious problem was that thanks to a recent SSL/TLS protocol vulnerability (CVE-2009-3555), several more things broke. The first problem was with stuff at work. I had been using the SSLCipherSuite option in a lot of our virtual host directives in Apache. The problem with that seemed to be that it always forced a renegotiation of the cipher being used, which would subsequently cause the session to die with "Re-negotiation handshake failed: Not accepted by client!?". Simply removing the SSLCipherSuite directive seemed to make all the clients happy again, but it's a lingering issue I'm sure, as is the whole mess in general since the protocol itself is having to be extended to fix this fundamental design flaw.

Along these same lines, I also ran into an issue trying to connect to my useful, yet often cantankerous Darwin Calendar Server. Everything was working just fine using iceowl to talk to my server's instance of DCS. And then, it wasn't. I'm fairly certain at this point that it's all related to changes made in Debian's version of the OpenSSL libraries, again, working around the aforementioned vulnerability. But the ultimate reality was, I couldn't connect with my calendar client any longer.

Once I pieced together that it was a problem with TLS1/SSL2, I simply configured my client to only allow SSL3. This works fine now with the self-signed, expired certificate which ships in the DCS source tree. I still can't manage to get things working with my perfectly valid GoDaddy certificate, but I'm happy with a working, encrypted, remote connection for the time being. My post to the user list describing the one change necessary to get Sunbird/iceowl working is here.

lighttpd, magnet, and more! posted Thu, 10 Dec 2009 17:44:26 -0600

by nipsy permalink

Today I was asked to deal with some broken e-mail marketing links we've been publishing for awhile now. We previously handled these misprinted URI's via PHP, but since we've moved all of our static content to lighttpd servers recently, this wasn't an option.

The solution it turns out was fairly straight forward. lighttpd does fortunately allow some amount of arbitrary logic during each request using LUA as part of mod_magnet. So after installing lighttpd-mod-magnet on my Debian servers and enabling it, I ended up adding the following to my lighttpd configuration:


$HTTP["url"] =~ "^/logos" {
        magnet.attract-physical-path-to = ( "/etc/lighttpd/strtolower.lua" )
}

and the following LUA script:


-- helper function to check for existence of a file
function file_exists(path)
        local attr = lighty.stat(path)
        if (attr) then
                return true
        else
                return false
        end
end

-- main code block
-- look for requested file first, then all lower case version of the same
if (file_exists(lighty.env["physical.path"])) then
        lighty.content = {{ filename = lighty.env["physical.path"] }}
        return 200
elseif (file_exists(string.lower(lighty.env["physical.path"]))) then
        lighty.content = {{ filename = string.lower(lighty.env["physical.path"]) }}
        return 200
else
        -- top level domains to search through
        local tld = { ".com", ".net", ".info", ".biz", ".ws", ".org", ".us" }
        for i,v in ipairs(tld) do
                local file = lighty.env["physical.path"]
                file = string.sub(file, 1, -5)
                if (file_exists(string.lower(file .. v .. ".gif"))) then
                        lighty.content = {{ filename = string.lower(file .. v .. ".gif") }}
                        return 200
                end
        end
        return 404
end

And that was it! The script checks for the existence of the requested file, and if it fails, it first forces the string to lowercase (since someone in our marketing department felt it would be a good idea to use mixed case URI's in our marketing publications) and failing that, it will also look for the same file with a few top level domains inserted into the name (again, brilliance by someone in marketing publishing crap with the wrong file names).

Failing all of that, you get a 404. Sorry, we tried.

OpenSolaris and ZFS for the win! posted Thu, 10 Dec 2009 02:51:57 -0600

by nipsy permalink

The whole reason I started writing this little blog system was so I could point out technical crap I run across. I imagine this is why most technical folks start blogging actually. It's more of a reminder than anything else and it's nice to be able to go back and reference things later, long after I would have normally forgotten about them.

Anyway, I recently built a huge software based SAN using OpenSolaris 2009.06 at work. The hardware was pretty basic stuff, and included a SuperMicro MBD-H8Di3+-F-O motherboard, 2 AMD Istanbul processors (12 cores total), 32GB of RAM, and 24 Western Digital RE4-GP 7200RPM 2TB hard drives, all stacked inside a SuperMicro SC846E2-R900B chassis. The total cost was a little over $12,000.

Needless to say, this thing is a beast. Thanks to a little help from this blog post which pointed me to a different LSI firmware available here, I was able to see all 24 drives and boot from the hard drives. One thing to note though was that I did have to disable the boot support of the LSI controller initially to get booting from the OpenSolaris CD to work at all. Once I had installed everything, I simply went back into the controller configuration screen, and re-enabled boot support.

After getting everything up and running initially, it was then a matter of installing and configuring everything. I found the following pages to be rather invaluable in assisting me in this:

  • this will get you up and running almost all the way on the OpenSolaris side using the newer COMSTAR iSCSI target
  • this will get you the rest of the way on OpenSolaris with the all important views needing to be established at the end of it all
  • this will get your Windows machines setup to talk to this new iSCSI target on the network

And that should be all you need! So far things have been running well. My only problem so far was making the mistake of upgrading to snv_127 which is a development version. The MPT driver broke a bit somewhere between that and snv_111b which is what the 2009.06 release is based on. The breakage would cause the system to bog down overtime and eventually hang completely. Not acceptable behavior to say the last on our shiny new SAN. There are a few posts about this issue here and here. I'll just wait until the next stable version to upgrade at this point.

cute HTTP Apache rewrite trick posted Tue, 08 Dec 2009 17:33:17 -0600

by nipsy permalink

I ran across a rather neat trick over here recently. So I don't forget about it (since I will probably end up needing to use it at some point), I'm going to copy it here.

The idea is to avoid duplicate rules when handling both HTTP and HTTPS based URI's. The trick is as follows:


RewriteCond %{HTTPS} =on
RewriteRule ^(.+)$ - [env=ps:https]
RewriteCond %{HTTPS} !=on
RewriteRule ^(.+)$ - [env=ps:http]

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)index\.html\ HTTP/ [NC]
RewriteRule ^.*$ %{ENV:ps}://%{SERVER_NAME}/%1 [R=301,L]

or the even shorter:


RewriteCond %{SERVER_PORT}s ^(443(s)|[0-9]+s)$
RewriteRule ^(.+)$ - [env=askapache:%2]

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /([^/]+/)*index\.html\ HTTP/
RewriteRule ^(([^/]+/)*)index\.html$ http%{ENV:askapache}://%{HTTP_HOST}/$1 [R=301,L]

my first real blog post posted Mon, 07 Dec 2009 18:39:14 -0600

by nipsy permalink

If you can see this, then my newly coded blog system is accepting posts as intended entirely via the web. Please take a moment to pray and give thanks to the wonders of modern science.