Django install script fails

Submitted by mkimmick on Thu, 09/03/2009 - 11:01

Trying to install django, 1.0.3 or 1.1. Fresh virtual server setup: example.com. Home directory /home/example.com/

Used all defaults for django install, click install, page sits on 'Installing...' and doesn't return:

Found http://www.djangoproject.com:80/download/1.1/tarball/ in cache .. Found http://www.saddi.com:80/software/flup/dist/flup-1.0.tar.gz in cache ..

Now installing Django version 1.1 ..

]#ps ax|grep python 14272 pts/1 SNs+ 0:00 su -s /bin/sh example.com -c /usr/bin/python manage.py syncdb 14273 ? SNs 0:00 /usr/bin/python manage.py syncdb

Killing these processes then allows error message to be printed to web interface:

  Database initialization failed at E-mail address :

   (Leave blank to use 'example.com'): example.com
  Error: That username is invalid. Use only letters, digits and underscores.
  Username (Leave blank to use 'example.com'): 
  Session terminated, killing shell... ...killed.

.. failed! See the error message above for the reason why.

Please advise.

Regards,

Mike Kimmick Nichewares & Consulting, LLC

Status: 
Closed (fixed)

Comments

Submitted by JamieCameron on Thu, 09/03/2009 - 12:32

Ok, I see the cause .. Django doesn't like an admin username with a . in it.

The work-around is to enter a different username on the script install form, such as just "example"

I will fix this in the next Virtualmin release.

Submitted by mkimmick on Thu, 09/03/2009 - 22:34

Okay. I wasn't sure what that option (initial login for script) was for, but I get a bit further now. However, now another error occurs during the install, see attached file.

The settings.py file is still created with the db username as 'example.com' instead of just 'example'. I think this is where the error is coming from.

Submitted by mkimmick on Thu, 09/03/2009 - 22:39

Actually, it doesn't matter what user I specify in the "initial login for script", the domain (or admin user) example.com is being set in the settings.py for the db username.

Maybe I'm missing a setting somewhere that specifies a username for databases?

Regards,

Mike Kimmick

Submitted by JamieCameron on Fri, 09/04/2009 - 02:19

That new error looks like it is happening because some tables were left over in the database.

Try removing all django* tables, deleting everything from the selected install directory, and re-trying the install.

Submitted by mkimmick on Sat, 09/05/2009 - 09:09

I did try removing the database and the project dir...same error.

Also worth noting, I'm trying to run the install script as root, rather than the domain's administrator account. Regardless, it should work.

Are there any manual instructions for installing django..that are current?

Submitted by mkimmick on Sun, 09/06/2009 - 13:30

Yes, I'm getting the same install error even though I start the install by creating a new database.

No, I don't have django already installed.

I'm interested in the manual install simply to try and track down the problem. This part of the traceback:

File "/home/example.com/public_html/lib/python/django/db/init.py", line 50, in ? connection = backend.DatabaseWrapper({ TypeError: init() takes exactly 1 argument (2 given)

has my interest. I'm curious to know what extra argument is being passed to the DatabaseWrapper function. My initial guess was that the username 'example.com' was being interpreted as python 'dot' notation and thus somehow being passed in as two arguments.

Also, if I could figure out how to run the syncdb command manually (in the context of virtualmin), that might be helpful too, since I can change the db username in the settings.py file, and re-run syncdb.

At the very least, running through a manual install of django, I should get a better idea of what part is failing. I looked through the django.pl script, but I'm not too familiar with perl, so it wasn't much help.

My hunch is that the ultimate source of the problem is because my setup uses usernames with periods or dots in them. Depending on the language, a period can mean several different things, as I'm quite sure you already know.

Submitted by JamieCameron on Sun, 09/06/2009 - 16:20

One thing you could try is running that failing step manually, as follows :

1) SSH into the system as the domain owner, and cd to the directory into which Django is being installed.

2) Set the PYTHONPATH variable with the command export PYTHONPATH=`pwd`/lib/python

3) Cd into the sub-directory for your project, which is myproject by default.

4) Run the command python manage.py syncdb , and answer the questions it asks.

Submitted by mkimmick on Sun, 09/06/2009 - 18:46

Okay, similar thing happens when running 'python manage.py syncdb' from the shell. Strange error about 2 args passed to init.py (in my project dir), but the 2 args are normal...['manage.py', 'syncdb']

I'm at a loss at the moment, but I think it must be something with the configuration of my virtualmin setup. I'm using /bin/false as the default shell...could this cause problems?

When I get a chance, I'll try the manual install, and if that fails, I'll try a system-wide install.

Submitted by JamieCameron on Sun, 09/06/2009 - 20:21

The shell shouldn't make any difference ..

What are you entering for the "Username" and "E-mail address" prompts?

Also, what does the settings.py file under the project directory contain?

Submitted by mkimmick on Mon, 09/07/2009 - 00:13

Okay, now this is strange. I was messing around testing accounts 'example.com' vs. 'example'. I had manually changed /etc/passwd and /etc/group, updating permissions on this accounts home dir...to no avail. Deleted the virtual server, made sure DBs were deleted and entries removed from /etc/passwd and /etc/group. I did notice one extra db named 'test' that I had in mysql...removed it. Manually removed home directory (had to change immutable bit on php5.fcgi due to manually messing arround with things). I then recreated the virtual server (to regenerate the error), and now django 1.1 installs fine...???

Maybe this was a bug with django, but I didn't find any recent and relevant post on django-users...?

Don't know what I might have done differently, or if some update fixed this, but I now at least have django installed in my test virtual server.

Now, onto testing my django app.

Thanks for your patience...especially on a holiday weekend!

Submitted by Issues on Thu, 09/24/2009 - 02:20

Automatically closed -- issue fixed for 2 weeks with no activity.