Categories: , , ,
Posted by: bjb

Handy quick conversion for timestamps in Nagios or unix logs: time.localtime (time.time);


bjb@bjb-pc:~/work/redmine/redmine-abitibi/app/views/mailer$ python
Python 2.5.2 (r252:60911, Jan 24 2010, 17:44:40)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.time
<built-in function time>
>>> time.time ()
>>> time.localtime (1284523200)
(2010, 9, 15, 0, 0, 0, 2, 258, 1)
>>> time.localtime (1284520137)
(2010, 9, 14, 23, 8, 57, 1, 257, 1)
Categories: ,
Posted by: bjb

Both before and after upgrading byteflow to use django 1.2, one thing that wasn’t working is postimage. The most recent problem was the link to post an image (in the admin page for creating or editing a blog post) was completely missing (whereas before it was present but malfunctioned).

The reason it was missing was that the javascript to create that link, in static/js/postimage.js, failed on line 42, in the showLinkFor function. It failed on


I fixed it by inserting the link before the blog text instead of after the previous node’s contents:

    //  showLinkFor: function(elem) {
    //      elem.previousSibling.appendChild(document.createElement('br'));
    //      elem.previousSibling.appendChild(this.getLink(;
    //  },

    showLinkFor: function(elem) {
        var parent = elem.parentNode;
        var mybr = document.createElement('br');
        var myid = this.getLink(;
        parent.insertBefore (myid, elem);
        parent.insertBefore (mybr, elem);

I have a non-standard URL_PREFIX of bjb/ and postimage didn’t play nice with that. I hard-coded my URL_PREFIX into the postimage.js file:

    getLink: function(id) {
        var link = document.createElement('a');
        link.setAttribute('href', '/bjb/admin/postimage/attach/?for=' + id);

Not elegant, but it got me past that problem. The next problem was that the list of files was empty. I set the POSTIMAGE_ROOT to point to a directory on the server machine with pictures in it, and then the list was not empty.

But it wasn’t full of all the pictures in that hierarchy either … that was just a file permission problem (web server couldn’t read some of them).

So now I can use postimage. It doesn’t do quite what I expected. What it does is allow you to choose among pictures on your server for inclusion into your blog. It doesn’t let you preview them. All it does is give you a list of files, and then put a link to the most recently chosen file in your blog text. You can call it over and over and it will add more image links. It looks like it can take the render method into account — there is a choice of markdown, html, rst. But, that choice was in the source code … not sure if it will detect your render method automatically.

I expected to be able to upload pictures to the blog … oh well. I guess the way postimage works is safer. It doesn’t put files up there for you — it assumes you have put them up already — into a “POSTIMAGE_ROOT” directory — and just accesses what is already there.

Posted by: bjb



During (1):


During (2):


During (3):


During (4):


During (5):


Look Ma! No load-bearing walls! … now how do you put this thing back together again ???

Posted by: bjb

I’m trying out byteflow under django 1.2, and I finally have it working. There were only a few changes to make.

First off, the databases are specified differently in django 1.2 — there is the option to connect to multiple databases now. Strangely however, django did not force me to change my database settings … I guess there is some backward compabitility stuff for now.


    DATABASE_ENGINE = 'postgresql_psycopg2'
    DATABASE_NAME = 'byteflow'
    DATABASE_USER = 'db_user'
    DATABASE_PASSWORD = 'sekrit'


    DATABASES = { 'default' :
            'ENGINE' : 'postgresql_psycopg2',
            'NAME'   : 'byteflow',
            'USER'   : 'db_user',
            'PASSWORD' : 'sekrit',

There are also some deprecation warnings in the logs about, in (I may have added all those ‘settings.BLOG_URLCONF_ROOT’ in when using ‘bjb’ as my URL_PREFIX):

    url(r'^%sadmin/(.*)' % settings.BLOG_URLCONF_ROOT,, name='admin'),

    url(r'^%sadmin/(.*)' % settings.BLOG_URLCONF_ROOT,

But this didn’t work for me so I went back to the old way. The problem was that when I asked to edit a blog post, it brought me to the main admin page. When I clicked on the Change link, it stayed on the main admin page. I’ll have to look into that another time.

An update was required to apps/tagging/managers, in usage_for_queryset, to update the database query for the django 1.2 database scheme (multiple databases). I found this hint.

Also, in order to run django 1.2 on my stable machine, I set up a virtualenv (with --no-site-packages) in which to run it. Had to install all the site-packages into the virtualenv:

  • BeautifulSoup-
  • Django-1.2.1
  • PIL
  • mx
  • openid
  • psycopg2-2.0.7

That’s about it except for infrastructure:

  • easy-install
  • pip-0.8
  • setuptools-0.6c8

Well I suppose I should have started by upgrading byteflow, I’ll have to try that another time. Maybe some of my changes have been fixed in upstream already. However I did quickly note that the byteflow install page still says it requires django 1.0.

Posted by: bjb

If you want to do some unattended operations on your postgres database, and if you haven’t specified that the user who will do those unattended operations has access to that database using ident or sameuser authorization in /etc/postgresql/M.N/main/pg_hba.conf, then you will have to give a password upon invocation. But, postgres commands generally don’t let you specify a password on the command line (and there is a good reason for this).

There are two ways to configure your admin user to be able to work on your postgres database. One is with an environment variable and the other is with a postgres password config file in the admin user’s home directory.

The environment variable to set is PGPASSWORD, for example export PGPASSWORD=sekrit; pg_dump mydatabase.

The config file method means writing lines like hostname:port:database:username:password into a file called .pgpass in the admin user’s home directory. Don’t forget to set the permissions on ~/.pgpass to 0400, or -r--------.

The reason why postgres strongly discourages specifying the password on the command line is that it is easy for other users on the system to see that password with a simple invocation of the ps command.

Categories: , , , ,
Posted by: bjb

If you’re running a slave nameserver using bind9 and you’re getting messages like this in your logs:

    Aug 31 19:58:30 sns named[12175]: zone refused notify from non-master: 2002:1234:cdef::1234:cdef#13361

then the master is sending out notifies on an IPv6 address. Normally, you could just add that address to the “masters” list in the zone on the slave, but if the master isn’t listening on IPv6 you’ll get a bunch of other errors, like this:

    Aug 31 07:32:33 sns named[12175]: zone refresh: retry limit for master 2002:1234:cdef::1234:cdef#53 exceeded (source ::#0)
    Aug 31 07:32:33 sns named[12175]: zone Transfer started.
    Aug 31 07:35:42 sns named[12175]: transfer of '' from 2002:1234:cdef::1234:cdef#53: failed to connect: timed out
    Aug 31 07:35:42 sns named[12175]: transfer of '' from 2002:1234:cdef::1234:cdef#53: Transfer completed: 0 messages, 0 records, 0 bytes, 189.000 secs (0 bytes/sec)

There are two ways to fix this: on the slave nameserver, or on the master.

 continue reading
Posted by: bjb

Using my blog for it’s intended purpose: notes to self.

django on my server is an older version, my apps developed on my desktop need a newer version of django. I need to deploy virtualenv on my server so I can run a newer version of django for some apps. Like ipaddr and byteflow.

byteflow in particular, needs jquery.js (for attaching an image to a post, via postimage app and TAGGING_AUTOCOMPLETE_JS_BASE_URL setting) and that is not included in django 1.0.2.

But I’m out of time for today, so this is a task for another day.

Posted by: bjb

Summary of emacs rectangle commands, with default keystrokes:

C-x r k    kill-rectangle
C-x r d   delete-rectangle
C-x r y   yank-rectangle
C-x r o   open-rectangle
C-x r c   clear-rectangle
M-x delete-whitespace-rectangle
C-x r t <text><enter>  replace rectangle contents with text (string-rectangle)
M-x string-insert-rectangle<enter><string><enter>  insert string on each line of the rectangle


Categories: , ,
Posted by: bjb

I created a new django app on my development machine running Debian SID (updated Aug 14-ish) and wanted to run it on my server machine running Debian stable (lenny). It didn’t work:

 machine    |           devel                   server
Debian      |        sid (Aug 14)           stable (lenny)
django      |            1.2                      1.0
python      |            2.6                      2.5

There were complaints about missing modules, missing middleware, etc etc. Commenting out those bits resulted in more complaints about other things. So I figured I’d just have to run a “private” copy of django for that application.

To figure out what to copy, I looked at the python-django package contents using

dpkg -L python-django

and that pointed me to this directory full of django implementation files:


So I copied that over to the stable machine next to the little application, told the application to use that django by inserting that directory at the beginning of PYTHONPATH in the wsgi script, and ran the application.

It couldn’t find the module core.handlers.wsgi

That file was there …. but no file in core/handlers.

It turns out there were lots of missing files … and it turns out that although Debian installs the django python implementation files in /usr/lib/pyshared/django, it uses them from another directory /usr/lib/pymodules/python2.6/django, which is a mirror directory structure with a bunch of links to /usr/lib/pyshared/django for the files in /usr/lib/pyshared/django, plus some other files (like the missing (and usually empty) files, plus a pile of .pyc files).

My guess is that Debian makes the mirror directory so that the .pyc files will not mess up the “source” install directory.

The upshot is, that if you’re going to run another django by copying django to a directory local to the application and altering the PYTHONPATH, copy the /usr/lib/modules/python2.6/django directory and not the /usr/lib/pyshared/django directory.

But, the better solution is to use python virtual environments (venv). My app is a tiny thing that only uses django and nothing else (django was really overkill for my app) but it’s a Bad Idea to solve the “wrong-django” problem this way. For example, any time a file disappears from the new version of django, my app would still find it in the old path (which didn’t get removed when I altered PYTHONPATH).

Posted by: bjb

Today is Debian’s 17th birthday. I sent them a thank you on the thank you page.