How to use proxycheck

[proxycheck]( is a small program design to (surprise) check for proxies. What’s not so clear, however, is how to use it. The default examples are for mail servers, which I guess was the thing to do back in 2004 when the last version was released. However, I need to adapt it for use with [pypsd]( Here’s how to check a host for open proxies in an IRC context:

./proxycheck -c "chat::real.irc" -d -aaaa

The chat parameter confused me for awhile until I figured out what it was for. proxycheck takes care of scanning ports and connecting to hosts using a number of methods, but once connected, you need some way to verify a real hit. -d tells proxycheck to try connecting to the supplied host:port, and -c chat:: tell it to try sending some text and scanning for watch. If it matches, you have a positive hit.

In the case of IRC, the first thing that happens when you connect to an IRC server is a series of notices from the IRCD (at least in hybrid), so watching for “real.irc” (e.g., replace this with part of your ircd’s hostname) is good enough

If you want more verbose output (checking the data stream), don’t bother with Wireshark. Just add -vvvv to the command.



Django On-Demand Model Fields

I’m writing an Inventory system for work in my downtime, part to brush up my rusting Django skills, part because we really need one.

We started with a few requirements for what would make a good inventory system to meet our needs, and one of those was that it would be painless to add new types of items and have the ability to customize them. If you know much about Django models, you probably know enough to know that models are typically hard-baked. If you’re writing a blog system, you might create a model with fields for Title, Author, Date, Text. Well for us, what if I want Widget X to have a field for Serial Number, and Widget Y to have a field for Firmware?

Well, one option is to write a model for each item. This unfortunately breaks both requirements- new item types must be added by the coder (me), and any changes to item properties also have to go through me. I don’t want to have to run constant maintenance here, so no thanks, I’ll pass on that.

What I’ve come up with instead are two models. One called ItemType, which consists of 3 fields: name, display, and custom_fields. The first two are self-explanatory. The last field is typically shown like this:


The second model is just called Item and contains common properties all items have: ID, Condition, Notes, etc; ItemType is a foreign key here.

A rather customized (but short and sweet!) ModelForm parses the custom_fields for the item type of a particular Item, and adds the fields (combobox or textfield depending on if you supplied choices), and the backend is managed by [django-expando]( so we can even have these custom properties in the first place.

I ran into a stupid Django bug when coding this, which prevented runtime fields from displaying in the ModelAdmin. The patch I’ve [documented and described](, but I’ve really little hope upstream will notice or even fix it. But should you want to do this in the future and it doesn’t work (e.g., it was never fixed), that’s what you’ll need to do.

There’s also this small, nasty recursion error expando is spawning off for reasons I’ve yet to figure out. I’ll nail it eventually. (UPDATE: upstream django-expando has fixed this, hoo-rah!)

But regardless, the dynamic typing system for this works really well and I’m kind of surprised and happy it turned out to be a success. Should it get to be proper production-level code, I’ll look into opensourcing it. For now, just get a hold of me if you’ve any questions about how to make this solution work.

So, Passenger is actually pretty useful

I have to admit, I’d heard of [Passenger/mod_rails]( before, but I only found out yesterday by chance that it also handles WSGI. Since most of any serious work I do is with Python, this caught my attention. Passenger turned out to be simple to setup, and braindead-simple to get running.

I’ve gone through several iterations of how to run my WSGI, from Apache mod_wsgi to Nginx mod_wsgi to Nginx proxy + CherryPy, and now back to Apache “mod_rails”. As an aside, Nginx mod_wsgi sounds like a good idea, but it isn’t. The author has written about this as well, and I encourage you to Google for more information.

One thing to remember when you setup your WSGI app with Passenger is that your file should be in the directory _above_ your DocumentRoot. So if your docroot is /var/www/, put the .py in /var/www/

I also run two redmines, so this simplifies that as well, since Passenger does rails primarily.

Goodbye, Nginx TCP proxying.

Importing Amarok 1.4 statistics into Amarok 2.2

This assumes you use mysql/external:

* Save your amarok <2.2 database:

mysqldump -uroot -p amarok > amarok.db #adjust for your system

* Re-import it as database “amarok1”
* Drop your original amarok database and let Amarok 2.2 otherwise re-create it.
* Look at amarok.urls.rpath and amarok1.statistics.url to determine the prepending path difference

Execute the following queries:

UPDATE amarok1.statistics SET url=REPLACE(url,"./", "./mnt/hdd750/"); /* replace "./mnt/hdd750/" with the prepending difference you saw in the earlier step */
INSERT INTO amarok.statistics (url,createdate,accessdate,score,rating,playcount,deleted) SELECT id,createdate,accessdate,percentage,rating,playcounter,deleted FROM amarok1.statistics s1 INNER JOIN amarok.urls u2 ON(s1.url=u2.rpath);

Preseto, Amarok 2.2 now has your old statistics.


Reverse Bitwise Flag Calculator

Sometimes when you need to deal with bitwise flags, it can get a little difficult to figure out what that gigantic number you’re using really consists of. The below should help:

#!/usr/bin/python - ./ 108 = flags that make up 108.
import sys
def decompose(i):
  limit = i+1
  tmpi = 1
  while tmpi < limit:
    if i & tmpi == tmpi:
      print tmpi
    tmpi *= 2
if __name__ == "__main__":
    b = int(sys.argv[1])
    print "You need to specify an integer"