Django script installers failure

Virtualmin
1

Hi Guys,
We have an odd one with the Django installer script, the script initially installed the python dependancies then failed. On running again we get:

Found http://www.djangoproject.com:80/download/1.4.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.4.1 …

Examining the running processes we still have even after the 5-10 minutes:

root 17006 1170 0 16:42 ? 00:00:02 /usr/share/webmin/virtual-server/script_install.cgi root 17088 17006 0 16:42 pts/0 00:00:00 sh -c su domainhere -c \/usr\/bin\/python\ manage\.py\ syncdb 1001 17089 17088 0 16:42 pts/0 00:00:00 su domainhere -c /usr/bin/python manage.py syncdb 1001 17090 17089 0 16:42 pts/0 00:00:00 sh -c /usr/bin/python manage.py syncdb 1001 17091 17090 0 16:42 pts/0 00:00:00 /usr/bin/python manage.py syncdb

We’re running Debian 6, with all packages up to date and Virtualmin 3.84gpl.
Has anybody seen this before?

Thanks,
Pete

2

Just tried deleting domain and recreating, plus also removed SSL in case it caused any issues. Now I get an additional step “Applying web server configuration” which might have been connected to the previous attempt which started off running as mod_php rather than fcgi.

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

Applying web server configuration …
… done

Now installing Django version 1.4.1 …

If I kill the script_install.cgi process I can then reinstall with the same details, but I need to clear the public_html for it to continue. This completes with errors:

Applying web server configuration .. .. done

Now installing Django version 1.4.1 …

Database initialization failed at yes.no :

Creating tables ...
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)

More information on using this script can be found at http://www.djangoproject.com/.

… installation was only partially complete.

Applying web server configuration …
… done

In this case the database seems populated, but no additional work has been done in the apache config for anything other than php to execute.

Any help would be appreciated,
Thanks,
Pete

3

I have the same issue with virtualmin 3.99.gpl and Django 1.5.1 or 1.4.3.

I have killed only the ‘manage.py syncdb’ process, to skip database sync. After that the script has finish normaly.

And in logs, I see that the script wait for an email address :

Now installing Django version 1.5.1 …

Database initialization failed at E-mail address :

 (leave blank to use 'be'): be
Email address: Terminated

More information on using this script can be found at http://www.djangoproject.com/.

… installation was only partially complete.

Applying web server configuration …
… done

After that I have manualy launched manage.py syncdb to complete the database installation.

4

I have the same issue. It hangs installing django 1.5.1 but killing the manage.py process finishes the install with the error you have. When I manually run manage.py (found in the django project directory) I get this…

Traceback (most recent call last):
File “manage.py”, line 8, in
from django.core.management import execute_from_command_line
ImportError: No module named django.core.management

To fix I had to set the PYTHONPATH variable as the user using django (reported here http://www.virtualmin.com/node/23146).

export PYTHONPATH=/home/USERNAME/public_html/lib/python

Then I can run the manage.py syncdb command and use django.

For reference I’m running…

  • Operating system - Ubuntu Linux 12.04.2
  • Webmin version - 1.630
  • Virtualmin version - 4.00.gpl GPL
  • Theme version - 8.7
  • Time on server - 24/May/2013 02:56 , Up 2 days, 0 hours, 9 minutes
  • Kernel and CPU - Linux 3.2.0-43-generic on x86_64
5

My system is practically identical to blissend’s - the only difference is that I’m Linux 3.2.0-41 instead of -43 - and I’m getting the identical issue.

I’m reading through the installer script - what a pity that the Django installer script is in Perl, a language I’m personally rusty in because, well, I switched to Python many years ago.

The Perl is quite hard to read - the author doesn’t seem to believe in indenting function bodies, and I’d forgotten that Perl has that stupid argument passing convention - but it does seem to try to set PYTHON_PATH on line 205:

$ENV{‘PYTHONPATH’} = “$opts->{‘dir’}/lib/python”;

Unfortunately, trying to figure out how and where $opts was set seemed doomed to failure. I’m assuming it’s from the initial form, but that isn’t getting me very far.

The script also seems to have some sort of error handling - but again, that can’t be working.

I see that someone did get this running sometime last year, but generally I’m seeing a lot of people with troubles similar to mine.

I haven’t tried the workaround, but this does scotch my plan to try to get users off PHP… at least two users want to use Django right now, and I’ll do it for them by hand but…

Wish I could contribute to fixing this but I don’t really understand Perl enough to fix this… but it’d be great if someone looked at it.

6

I forgot to mention an important point:

There’s also an issue with the “Install sub-directory under public_html” field.

There’s a note there saying “Warning - Django works best when installed at the top level.” - which is fine by me (though shouldn’t “install at top level” therefore be the default?)

Unfortunately, if I select “At top level” there doesn’t seem to be any way to fill in the form field to get an installation that isn’t in public_html.

If I for example give the absolute pathname /home/USERNAME then Django appears to be installed in /home/USERNAME/public_html/home/USERNAME - very much not what I want.

If I give the pathname / then it warns me that if I install in /home/USERNAME/public_html then it will erase everything when it uninstalls. The warning is really useful! but still doesn’t give me any way to install somewhere else.

And if I leave it blank I get an error.

I wonder if there’s a form programming error where the roles of these two settings were reversed?

UPDATE: nope - switching that switch doesn’t help at all, the same warning. I also tried the directory “…”

Lots of time wasted on this today… it would have been better for me if this script didn’t exist at all.

7

Howdy,

Install Scripts are only designed to be put into the public_html dir, and sub-directories underneath that.

However, if you’re attempting that, and it’s not working – that probably warrants a bug report.

My suggestion would be to file a report using the Support link at the top of the page, and to describe the problem that you have while performing an install. Jamie will then be able to work with you to figure out what’s going awry.

-Eric

8

Thanks, I’ll do that (probably tomorrow, today’s a day off!)

Install Scripts are only designed to be put into the public_html dir, and sub-directories underneath that.

Hmm, that doesn’t seem entirely wise.

After having my server subverted a few weeks ago (due to an uploaded Trojan in a WordPress style, beware!) I’ve been doing a lot of reading about security issues.

One of the pieces of advice that is common to many of the sources is NOT to put your installations within public_html. The reason is simple - the installation contains a lot of executable code that you might not want to be directly called, but more, it likely contains passwords - stored in the clear!

Now, supposedly .htaccess will protect you but in practice this is not iron-clad.

First, there are numerous ways of getting around .htaccess (search for “bypass htaccess” or “htaccess exploit”). Most if not all of these require some other weakness in your system - but as I’ve been discovering, the key to security is “belt and suspenders” - you do not want one weakness to open your system up completely.

Second, writing a correct .htaccess is an arcane art. There’s no guarantee that the creator of the package you have really did it right - but more, the user often end up having to tweak the .htaccess to get your package to work on your installation - and frustrated users have been known to turn off the protections on the .htaccess entirely in order to get past obscure bugs.

By keeping your installation out of public_html, you guarantee that by default the web server cannot see these files. You’re getting rid of a lot of the problems I’ve described above - for no work on the user’s part at all.

Just my $0.02! Thanks for a great system.

9

Howdy,

I think we got to the bottom of the issue with the Django Script Installer. The next version of the Script Installer should correct the problem.

-Eric