Hi all,
I've written a virtualmin script installer for Django (Python web framework) which is able to install from source files or from the subversion repository. It works quite good and allows server admins to install it as a requirement for Django-based apps (just like rails for example).
But there is a problem, of course: Wouldn't it be great to deal with more Python based software, not only Django? Not knowing how things work here in the forum, I'd like to propose to add support for Python as a possible language, extending the list of ruby, perl and php. There is a CPAN- and rubygems-like repository for Python modules at pypi.python.org (Python Package Index) that could be useful for automatic installation. Specifically the setuptools and its "easy_install" command can deal with dependency tracking and other advanced package management techniques. There is of course a large variety of Python packages in every OS package repository.
Is there somebody else interested in Python support?
Cheers, Jannis<br><br>Post edited by: jezdez, at: 2007/12/11 16:29
Yes, I would LOVE to see some Python support on Virtualmin. A nice GUI to pypi would be pretty slick, and most linux distro's have Python installed by default, so it's not like there'd be many dependency issues.
By the way, any chance on getting the code for the auto-Django install?
Hi,
The Virtualmin-Pro install script for Django worked well enough.
However I have some questions, please see:
http://www.virtualmin.com/index.php?option=com_fireboard&Itemid=77&a...
Thanks.
Jamie and I both like Python quite a lot, it's just not been as in demand as the other languages we support. I certainly won't rule out support for pypi (I didn't actually know about pypi until a couple of days ago...when I was working with Python, there was no CPAN-like creature, though Python Eggs seemed to be poised to make it possible) and some of the more popular Python applications (Moin and trac come to mind, though trac is a dependency nightmare, so it'll be further down the road).
I know we have a few customers running Zope and/or Plone, as well, though it's also one of those things that's almost impossible to automate because of a dastardly dependency chain and dramatic resource requirements.
--
Check out the forum guidelines!
Great to hear that!
An interface for pypi would be great, indeed. I'll look into the plugin system, if it's possible to create something for Virtualmin to make this happen. Unfortunately my skills in Perl are somewhat limited.
Yes, I'll write an article about that tomorrow and post it on my blog and here. Btw, I just figured out how to use mod_fcgid in a smooth way with Django, having a considerably better performance than with mod_python (on Virtualmin Pro). Woohoo!
Perspectively, I would use mod_wsgi with any Python app since it brings even more performance and was made for Python (http://www.python.org/dev/peps/pep-0333/). Have a look at http://code.google.com/p/modwsgi/wiki/InstallationInstructions for detailed information and a list of application setup descriptions. This is all possible via Apache conf or .htaccess files, so setup support from within Virtualmin shouldn't be neccesary in the first place. But I would welcome this very much.
Joe, you are right, there are a lot of dependencies to track down with Zope and Plone. The good news is, that each virtual user could have it's own site-packages (default Python packages directory) directory in the home directory. Setuptools' "easy_install" command is also able to automatically download and install from the PyPI to a non-system path. Database interface modules and other popular packages could be installed system-wide, of course.
Please let me know if I can help to speed things up or something.
Hi again,
I now had the time to finish my article about using Django with Virtualmin:
http://jannisleidel.com/2007/12/howto-use-django-on-a-virtualmin-server/
The only thing I'm still unsure about is a nice way to kill the fcgi process to let it respawn automatically (wihtout using the obvious kill command), e.g. when I change the code of a Django-based app.
I know with mod_fastcgi it's possible to just "touch" the fcgi file, though this doesn't work with mod_fcgid :-/ Any ideas?
Best,
Jannis
dud you rocks ....... im testing it and report my observations
The install script works very nicely (Thank you!), and everything is setup in accordance to the blog entry, but I'm getting a 403 Forbidden error:
"<b>Forbidden</b>
You don't have permission to access /mysite.fcgi/ on this server."
mysite.fcgi is chmodded to 0755.
Any ideas?
Hm, strange,
Are you accessing the site via http://url.tld/ or http://url.tld/mysite.fcgi/ ?
Does the mysite.fcgi file belong to the user of the virtual host?
Have you PHP over fcgid activated?
<div class='quote'>Are you accessing the site via http://url.tld/ or http://url.tld/mysite.fcgi/ ?</div>
I'm accessing it through http://url.tld/ .
<div class='quote'>Does the mysite.fcgi file belong to the user of the virtual host?</div>
Yes.
<div class='quote'>Have you PHP over fcgid activated?</div>
Hmm?
I was just wondering if the apache configuration contains the ExecCGI permission.
Maby we cold compare our Apache configuration. The configuration of a virtual server here with a running Django app (/etc/apaches/sites-available/USERNAME.com.conf) is:
...
<Directory /home/USERNAME/public_html>
Options Indexes IncludesNOEXEC FollowSymLinks ExecCGI
allow from all
AllowOverride All
AddHandler fcgid-script .php
AddHandler fcgid-script .php4
AddHandler fcgid-script .php5
FCGIWrapper /home/USERNAME/fcgi-bin/php4.fcgi .php
FCGIWrapper /home/USERNAME/fcgi-bin/php4.fcgi .php4
FCGIWrapper /home/USERNAME/fcgi-bin/php5.fcgi .php5
</Directory>
..
Ah, progress... I added ExecCGI and now I'm getting an Internal Server Error.
Though this sounds weird but this should be a good sign :)
Try to look in /home/USERNAME/logs/error_log or in /var/log/apache2/error.log (or whereever your apache's error log might be)
<div class='quote'>[Thu Dec 20 11:46:24 2007] [warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error.
[Thu Dec 20 11:46:24 2007] [error] [client x.x.x.x] Premature end of script headers: mysite.fcgi</div>
By the way, I really appreciate all your help, jezdez. :)
Ah, wait a sec, maby you haven't switched to "FCGId (run as virtual server owner)" as "PHP script execution mode" under Server Configuration > Website Options.
Also make sure the mod_fcgid Apache module is enabled.
<div class='quote'>Ah, wait a sec, maby you haven't switched to "FCGId (run as virtual server owner)" as "PHP script execution mode" under Server Configuration > Website Options.</div>
I set it to "FCGId (run as virtual server owner)", still no dice.
<div class='quote'>Also make sure the mod_fcgid Apache module is enabled.</div>
It is.
Quick question: why would "PHP script execution mode" have any effect? PHP != Python
I actually asked because of the fcgid module, since I assumed you have PHP running via mod_fcgid. So yes, PHP is not Python, thank god.
Do you also have set "Run CGI scripts as domain owner?" to yes?
Apparently my problem lies deeper...
I created a test.php script (<?php print 'hello world'; ?>), and I'm getting the same error:
<div class='quote'>[Thu Dec 20 14:07:46 2007] [warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error.
[Thu Dec 20 14:07:46 2007] [error] [client x.x.x.x] Premature end of script headers: test.php</div>
<div class='quote'>Do you also have set "Run CGI scripts as domain owner?" to yes?</div>
Indeed I do.
<div class='quote'>So yes, PHP is not Python, thank god.</div>
Amen to that! :)
Hmpf, what else could that be...?
Anyone else? Joe?
<div class='quote'>[Thu Dec 20 14:07:46 2007] [warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error.
[Thu Dec 20 14:07:46 2007] [error] [client x.x.x.x] Premature end of script headers: test.php</div>
This particular error might be an issue I just saw on another users box...check ~/etc/fcgi-bin/php5.fcgi to be sure the php binary that is being called is a php-cgi binary, rather than a php-cli (or just php, possibly, depends on the OS/version). If it's the CLI variant it is feeding out results without proper headers and Apache refuses to serve them.
But, that wouldn't explain Python problems.
It could also just be permissions. If you have the "it wasn't working, so I chmod 777'ed it just to be SURE it wasn't a permissions problem" instinct, you'll want to revert back to 750 or less (suexec will never run anything that is world or group writable).
--
Check out the forum guidelines!