How to get Django 1.x running on SUSE Linux Enterprise Server 10 (x86_64)

October 12, 2010 in Articles with Comments Off

For my non-developer readers: This is a technical post, and it might make your head explode. Be careful.

TLDR:

SUSE Linux Enterprise Server 10 is very different from the flavors of Linux that I’m accustomed to working with (Debian/Ubuntu), and I ran into quite a bit of trouble getting Django installed. I can’t install packages myself, so it was even more slow going as every time I discovered I was missing something, I had to have a sysadmin do it for me.

Here’s the quick list of the packages that will get Django up and running on SUSE Linux Enterprise Server 10. Notice I’ve included MySQL. The database package you need may be different, and I’ll leave it up to you if you use something other than MySQL.

For reference, here is the full package listing for SUSE Linux Enterprise 10 Service Pack 2.

I wrote this just in case someone was unfortunate enough to have to go through this same process. Hopefully your search engine of choice will guide you here, and the next few hours of your life will be slightly less stressful than they could have been.

Read the details of my adventure “after the break”…

How to get Django 1.x running on SUSE Linux Enterprise Server 10 (x86_64)

Maybe I’m spoiled, or still considered a “noob”, but I use Ubuntu Server for
several of my own projects, and I’m moderately familiar with the Debian style
Linux setup and package management (via apt-get). When I first started learning
Python, and when I downloaded Django (trunk, just before 1.0), I didn’t
encounter any trouble with missing bits of Python, or other packages.

At my day-job, I’m in the process of trying to get a Django project up and running
on an official development SLES/SUSE Enterprise server. This, of course,
to get everything going smoothly before attempting the same process on the
production server.

This all almost happened quite a while ago, except for the fact that I am not
in direct control of the servers in question. We have a sysadmin that has plenty of
things to do, and working with me to figure out what packages need to be
added to a development box just wasn’t worth the effort at the time. He doesn’t
mind installing packages that I need (via the graphical yast system), but because
of our service contracts, he doesn’t install anything that isn’t supported: which
is anything not found via yast. So that’s no big deal. The real problem is, until now,
I had no idea what packages I needed installed, as I’d never gone through this on
a SUSE system, and had no idea how they separated things.

Forward to the future. The project, at least its initial phase, is nearing developmental completion, and needs to go into official testing/acceptance mode.

Incomplete!

The directions you’ll see below are sparse, and do not fully detail the Django
installation process. At this time I’m only documenting the problems I came across,
as I’m still not yet completely familiar with the way Novell/SUSE splits up
their ‘packages’.

What version are you running?

Running `sudo cat /etc/SuSE-release` gives the following output:

SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 2

If I’m not mistaken, ‘PATCHLEVEL’ here indicates the Service Pack installed. At the time of writing, there is a Service Pack 3, but I believe this indicates that our current setup is still using 2.

The version of Python installed with SUSE Enterprise 10 is Python 2.4.2.

As you may know, Python 2.4 doesn’t come with native SQLite support, so
if you’re using that, you may have to install a separate package for SQLite support. We are currently using MySQL in Production for this project, so I of course
needed the `python-mysql` package.

Not so easy?

I like to use things like ‘pip‘ and ‘easy_install’, and thought that this
time I would take the easy route and even try out `easy_install django`. Alas, there was no `easy_install` available. Nor is distutils or setuptools available. For that, I eventually discovered I would need the package `python-devel`.

After installing `python-devel` I was able to get `easy_install` up and running. Only after I manually downloaded the `easy_install` package, and ran the required `python setup.py install`.

I was then able to install Django, even able to view the “Welcome to Django” page after running `pythong manage.py runserver [ip]:8080`.

Great!

So I quickly made my usual changes to the Django settings file, filling out the database information to match my tested-and-working MySQL database setup,
and attempted a the first `syncdb`.

Augh! I was getting exceptions about the wrong version of `MySQLdb` module. It seems that the Python module `MySQLdb` that you get with SUSE Enterprise 10 is “2.0.0″, and the error message clearly tells me that I need version “2.2.2“.

So, I thought I’d be clever and do `easy_install MySQL-python` (not “mysqldb”), which should install the updated version for me. Doing that started out looking good, but ended in errors similar to…

“mysql_config not found”

So back to the SUSE Package listings to find out where the heck this “mysql_config” program was. As it turns out, you have to install `mysql-devel` to get “mysql_config”, which will then allow you to manually install the newer version, via easy_install. With `mysql-devel` installed, you can finally run `easy_install MySQL-python` and it will work.

Admin and Auth

As most probably do, I use the built-in Admin and Auth systems, so I am prompted to create a Superuser for Django, during the first `syncdb`.

Right after giving the superuser name and password, I got the following exception:

‘ImportError: No module named xml.sax.saxutils’

Having never seen that before, I did some “Googling” around, and as any decently-adept Python user might do, I attempted to import the package from the Python command line, just to troubleshoot the problem.

Running `python`, and using `import xml` gave the following exception:

‘ImportError: No module named xml’

Man, that’s weird. Especially considering that the box is running Python 2.4.2! Checking the Python documentation showed that, of course, this was part of the Python Standard Library. But wait… Novell/SUSE decided to separate this from the main Python package. After I did a bit more “Googling” (other people having similar issues) and searching the package listings on the Novell website, I found that `sax.saxutils` is in the package `python-xml`.  I also noticed the `pyxml` package contains the path ‘site-packages/xml/’ so I had the sysadmin add them both, just to be thorough.

At this point, the Python interpreter can now successfully do `import xml`
as well as `from xml.sax.saxutils import XMLGenerator`, as Django was attempting.

From there, it seemed my Django installation was happy again, and I could move on.

Adding South

The next thing I wanted to add was South, to continue managing my database
migrations, at least during these last phases of development.

The `easy_install south` command seemed to work just fine, until actually
trying to do a migration. The release available at the time of writing time is ‘South 0.7.2′.

When I would attempt an actual migration, I was running into this exception:

[... snip ...]
File “/usr/local/lib64/python2.4/site-packages/South-0.7.2-py2.4.egg/south/db/generic.py”, line 129, in execute
get_logger().debug(‘south execute “%s” with params “%s”‘ % (sql, params), extra={
File “/usr/lib64/python2.4/logging/__init__.py”, line 947, in debug
apply(self._log, (DEBUG, msg, args), kwargs)
TypeError: _log() got an unexpected keyword argument ‘extra’

Once again, Google to the rescue. Here’s the search I used:

+django +south TypeError: _log() got an unexpected keyword argument ‘extra’

That immediately led me to a South Trac Ticket with great comments
and explanation of the exact problem I was running into. Here’s the description on the ticket:

The logging module in python2.4 doesn’t accept the ‘extra’ kwarg. It is used here:

http://south.aeracode.org/browser/south/db/generic.py#L129

This causes all migrations to fail with an exception.

The problem had already been fixed, and there was a link the chageset code,
with a Milestone listed as ’0.7.3′ (so not yet in the available release). I took a look at the offending line of code and noticed that it was such a simple change, I just went and applied the differences directly to the file on the development server (the path is listed in the error output).

As of now, everything appears to be running fine.

I wrote this post based on only a brief log I was keeping while setting things up, to ensure we could reproduce the same steps on the production machine. If I’ve left out something obvious, critical, I’m sorry. I may have also overlooked something that would have made my life a lot easier – oh, well.

Sorry, Comments are Closed.

You'll have to take it up with the author...