Django apps in HestiaCP? Django apps in HestiaCP!

yes that seems wrong, as the name for the process, which is the 2nd part ‘admin-django’ in your example has to be different for each vhost. if you run multiple vhost and they have the same name there you’ll see that ‘duplicate’ message.

from the template this should be put together from the web-domain plus the -django… part, hence

%domain%-django-ssl

or

%domain%-django

depending on the template… in your example it seem to more likely use %user%-django instead - maybe you can check your .tpl file again, if you just accidentically put the wrong var in there?

having %domain% there makes much more sense, as exactly that would be the key differantiator and not the user name :wink:

1 Like

That makes sense. Thanks for the tip. I’m going to try right away. Hopefully that will fix it. Thanks!

Mmmm… It seems that that’s not the solution, but it’s probably pointing in the right direction. I will continue working on it. Thanks @falzo!

1 Like

might sound like a bit of a poor mans approach, but you could run something like

find /etc /home -type f -exec grep 'WSGIDaemonProcess' {} \; -print

and check the ouput… according to the error you should see a name for that procces at least twice and the files which contain these lines :wink:
maybe that helps to narrow it down. I have a feeling that you are quite close already…

Yeah, I tried that, but it was appearing only once…

I really have interest in making this work because I see PHP too limited… And definitely more insecure than Python. But I’m running out of ideas on how to fix this…

This is what I find so far:

root@host1:/home# find /etc /home -type f -exec grep 'WSGIDaemonProcess' {} \; -print
    #WSGIDaemonProcess directive instead. 
/etc/apache2/mods-available/wsgi.conf
        WSGIDaemonProcess myweb.site-django user=admin group=admin processes=1 threads=5 display-name=%{GROUP} python-home=/home/admin/web/myweb.site/public_html/venv/ python-path=/home/admin/web/myweb.site/public_html/venv/lib/python3.6/site-packages socket-user=admin
/home/admin/conf/web/myweb.site/apache2.conf
        WSGIDaemonProcess myweb.site-django-ssl user=admin group=admin processes=1 threads=5 display-name=%{GROUP} python-home=docroot%/venv/ python-path=/home/admin/web/myweb.site/public_html/venv/lib/python3.6/site-packages
/home/admin/conf/web/myweb.site/apache2.ssl.conf

Everything at /etc/apache2/mods-available/wsgi.conf is commented out, so that leaves the other 2 files, which have different names for the process…

UPDATE:
I also found this tutorial, but it’s not working for me. And at this point I don’t know if it’s because I messed something with my server… https://danieldevine.dev/creating-a-vesta-control-panel-template-for-django-projects-python-3-with-apache-nginx-virtualenv-and-mod_wsgi-on-ubuntu-server-16-04/

weird, I googled around a bit more and came across this: https://stackoverflow.com/questions/39317200/name-duplicates-previous-wsgi-daemon-definition

which also mentions

WSGIProcessGroup

from the snippet of your tpl/stpl you posted first it seems to be in there… from the quote of the ready made config later it seems to be missing. maybe run the same find for the processgroup again and check if it’s there at all and differs for ssl vs non-ssl.

I know it’s grasping at straws though… I am simply also running out of ideas, but I strongly believe that the error message is usually very close to the real problem :wink:

1 Like

All ideas are welcomed, even if they are just wild thoughts or random guessing.

I tried with WSGIProcessGroup and also adding process-group=%domain% to WSGIScriptAlias as suggested in another StackOverflow posts… Still the same.

At the moment I managed to have a WSGI process group not yet configured error with this wsgi_django.tpl template:

<VirtualHost %ip%:%web_port%>

    ServerName %domain_idn%
    %alias_string%
    Server%user% %email%
    DocumentRoot %docroot%
    ScriptAlias /cgi-bin/ %home%/%user%/web/%domain%/cgi-bin/
    Alias /vstats/ %home%/%user%/web/%domain%/stats/
    Alias /error/ %home%/%user%/web/%domain%/document_errors/
    SuexecUserGroup %user% %group%
    CustomLog /var/log/%web_system%/domains/%domain%.bytes bytes
    CustomLog /var/log/%web_system%/domains/%domain%.log combined
    ErrorLog /var/log/%web_system%/domains/%domain%.error.log
        
    IncludeOptional %home%/%user%/conf/web/%domain%/apache2.forcessl.conf*
    
    <Directory %home%/%user%/web/%domain%/stats>
        AllowOverride All
    </Directory>
    <Directory %sdocroot%>
        AllowOverride All
    </Directory>

    Alias /static /home/%user%/web/%domain%/private/django/app/static

    <Directory /home/%user%/web/%domain%/private/django/app/static>
        Require all granted
    </Directory>

    Alias /static /home/%user%/web/%domain%/private/django/app/static
    <Directory /home/%user%/web/%domain%/private/django/app/static>
        Require all granted
    </Directory>

    Alias /static /home/%user%/web/%domain%/private/django/app/media
    <Directory /home/%user%/web/%domain%/private/django/app/media>
        Require all granted
    </Directory>
    
    <Directory /home/%user%/web/%domain%/private/django/app/app>
        <Files wsgi.py>
            Require all granted
        </Files>
    </Directory>

    SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0

    IncludeOptional %home%/%user%/conf/web/%domain%/%web_system%.conf_*

    <IfModule mod_wsgi.c>
        WSGIDaemonProcess %domain%-ssdsd socket-user=%user% python-home=/home/%user%/web/%domain%/private/venv python-path=/home/%user%/web/%domain%/private/django/app
        WSGIProcessGroup %domain%-ppp
        WSGIScriptAlias / /home/%user%/web/%domain%/private/django/app/app/wsgi.py process-group=%domain%-ppp application-group=%{GLOBAL} 
    </IfModule>


</VirtualHost>

I’m using journalctl -xef to see the errors in real time. If anyone wants to give it a try, please be my guest.

With the error that I’m having, the conflicting line is:

WSGIScriptAlias / /home/%user%/web/%domain%/private/django/app/app/wsgi.py process-group=%domain%-ppp application-group=%{GLOBAL} 

Oddly enough, I found that other people also managed to have this running in VestaCP and a template like the one I’m writing. You can take a look at https://gitlab.com/neyder/vestacp-wsgi/-/tree/master/

I simply can’t understand why mine is not working.

OK, I think I’m giving up on WSGI for doing this… I will look for a different approach instead. :persevere:

Maybe try this:

I think that’s the one he tried already…

@realjumy I am very sorry, I ran out of ideas and don’t really have the time (or app/use case) to dig into and try out…

Yes, that’s one one the different approaches I tried. Maybe because how HestiaCP is designed there’s something that’s is causing the error with the duplicated names. I will try using an alternative to WSGI, maybe that way it works.

As I said, I have particular interest in making this work because I find PHP very limited and insecure. If make it work I think it’s just natural to share the way to do it with the community.

1 Like

Just a note: Python is much older than PHP yet still php became the de facto backend platform in the early 2000s and this didn’t hapend because it was limited or insecure.

The recent hype python enjoyed in the recent years is mostly related to usage in data science fields, but on the web front not much has improved in the last 2 decades, as even this one month old thread shows; setting apache to serve multiple python apps shouldn’t take this long, even for a beginner.

This being said, extending support for other backends like python,node,deno or lxc/docker is something we will have to improve in the future

How relaxed/random are the content types in PHP is one of the multiple examples of how insecure it is. PHP was a good option years ago, but I don’t see many reasons to stick to it when there are many other alternatives (not just Django).

I have installed and running several websites using Django. The difficulties here are related to make it run with HestiaCP.

This is an interesting debate, although I would like not to divert too much from the main topic of the original post.

I have skimmed trough the thread and the problem is definitely not related to Hestia but with the Apache vhost config (maybe even python venv or wsgi entrypoint).
After all Hestia is just copying the template to apache and resolves the placeholder values if finds there (like %domain% %user% etc). When creating the template you have complete freedom to add anything you want there.

So if you have a standalone Apache config able to handle multiple wsgi apps it should not take more than a couple minutes to convert it to a template.

PS OT: Relaxed types are common to most dynamically typed lang like py,js,perl,ruby and that does not make them insecure. If you prefer more strict types then C#, golang might be worth looking into. (Last comment on this subj)

2 Likes

OK, after much frustration and suffering, I decided to ditch the idea of using WSGI. I decided to change to Gunicorn… And it simply works.

Disclaimer:

  • I am not responsible for any problem derived from its installation or use. This piece is software is provided as it is.
  • These templates are intended for HestiaCP 1.1.1 running on Ubuntu 18.04
  • Read the instructions in the repository carefully.
  • Further configuration is needed after the installation of the Django App.
  • Not suitable for the faint of hearth, as it can break your server.
  • At the moment it is intended for 1 single Django installation in the entire server (not just per domain or user, I mean the entire server)
  • If you are giving it a try, you better know what you’re doing.

CAUTION, THERE MIGHT BE DRAGONS:

Feel free to test it and contribute.

2 Likes

OK, new release, in case someone wants to test it:

I also noticed something while I was “hunting dragons” in the code. If you check the lines 42-51 in Django_app.sh you will notice that there are some lines commented out. This is because for some strange reason, the if that adds content to the file in case it exists (which by the way, I know that the piece of code that I was attempting to add is wrong) is being executed after the next if. This might be (or might not be) the cause why WSGI approach of these templates is not working.

Is anyone able to try these templates, please? You should be able to finally see this error when you access to your domain:
Django_error

But it is solved just adding your domain and IP to the section ALLOWED_HOST in the Django app configuration and then restarting gunicorn with systemctl restart gunicorn.

It’s also necessary to follow this order to activate the templates (applying after each change):

  1. Select Django_proxy_pass as NGINX template
  2. Select Socket as Backend Template PHP-FPM (not sure if this is necessary)
  3. Select Django as Apache2 template.

In the next iteration I will sort the limitation of only 1 Django app per server.

1 Like

awesome, thanks for sharing! I am sure that will be helpful for other searching around that topic!

2 Likes

I’m finishing the last touches to the templates for installing and using CodeRedCMS :wink:

1 Like