You aren't defining a VirtualHost for port 443 for app2.com <http://app2.com/>.
In the app1.com <http://app1.com/> you have VirtualHost for both port 80 and 443 with port 80 redirecting to 443. You would need similar arrangement for app2.com <http://app2.com/>. Graham > On 8 Jul 2021, at 8:24 pm, Amber L <[email protected]> wrote: > > Hi, > > I also have a similar problem. I have two flask apps with separate domains > but only the first is working properly. HTTPS only applies in the first > domain app1.com <http://app1.com/>. Below is the conf file. > > Any ideas on what I may be doing wrong? > > > # app1. com > > <VirtualHost *:443> > ServerName app1.com <http://app1.com/> > ServerAlias app1.com <http://app1.com/> *. app1.com <http://app1.com/> > ServerAdmin [email protected] <mailto:[email protected]> > > # WSGI Settings > WSGIDaemonProcess app1 user=apache threads=7 > python-home=/var/www/app1/venv > WSGIScriptAlias / /var/www/app1/wsgi.py process-group= app1 > application-group=%{GLOBAL} > WSGIScriptReloading On > > # Tell Apache where your app's code directory is > DocumentRoot /var/www/app1 > > # Logging > ErrorLog /var/www/app1/logs/app.log > CustomLog /var/www/app1/logs/access.log combined > LogLevel info ssl:warn > > # Relax Apache security settings > <Directory /var/www/app1> > <Files site.wsgi> > Allow from all > Options -MultiViews > Require all granted > </Files> > </Directory> > > Alias /static /var/www/app1/application/static > <Directory /var/www/app1/application/static> > Allow from all > Options -MultiViews > Require all granted > </Directory> > > > RewriteEngine on > RewriteCond %{SERVER_NAME} = app1.com <http://app1.com/> [OR] > RewriteCond %{SERVER_NAME} =*. app1.com <http://app1.com/> > RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} > <https://%{SERVER_NAME}%{REQUEST_URI}> [END,NE,R=permanent] > SSLEngine on > SSLCertificateFile /etc/letsencrypt/live/app1.com/cert.pem > <http://app1.com/cert.pem> > SSLCertificateKeyFile /etc/letsencrypt/live/app1.com/privkey.pem > <http://app1.com/privkey.pem> > Include /etc/letsencrypt/options-ssl-apache.conf > SSLCertificateChainFile /etc/letsencrypt/live/app1.com/chain.pem > <http://app1.com/chain.pem> > > </VirtualHost> > > <VirtualHost *:80> > ServerName app.1com > > WSGIScriptAlias / /var/www/app1/wsgi.py application-group=%{GLOBAL} > </VirtualHost> > > > # app2.com <http://app2.com/> > > <VirtualHost *:80> > ServerName app2.com <http://app2.com/> > ServerAlias app2.com <http://app2.com/> *.app2.com <http://app2.com/> > ServerAdmin [email protected] <mailto:[email protected]> > > # WSGI Settings > WSGIDaemonProcess app2 user=apache threads=7 > python-home=/var/www/app2/venv > WSGIScriptAlias / /var/www/app2/wsgi.py process-group= app2 > application-group=%{GLOBAL} > WSGIScriptReloading On > > # Tell Apache where your app's code directory is > DocumentRoot /var/www/app2 > > # Logging > ErrorLog /var/www/app2/logs/app.log > CustomLog /var/www/app2/logs/access.log combined > LogLevel info ssl:warn > > # Relax Apache security settings > <Directory /var/www/app2> > Allow from all > Options -MultiViews > # Uncomment this if you're on Apache >= 2.4: > Require all granted > </Directory> > > Alias /static /var/www/app2/application/static > <Directory /var/www/app2/application/static> > Allow from all > Options -MultiViews > Require all granted > </Directory> > > > RewriteEngine on > RewriteCond %{SERVER_NAME} =app2.com <http://app2.com/> [OR] > RewriteCond %{SERVER_NAME} =*. app2.com <http://app2.com/> > RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} > <https://%{SERVER_NAME}%{REQUEST_URI}> [END,NE,R=permanent] > </VirtualHost> > > > Thanks in advance for your help. > On Monday, January 8, 2018 at 12:06:29 AM UTC-8 [email protected] > <http://gmail.com/> wrote: > Hi > > So, that's fixed it, explicitly setting the script alias per vhost, now the > problems are no longer bleeding into the (non-django serviced) additional > vhost. > > Thanks > Shane > > > On Monday, January 8, 2018 at 6:35:55 PM UTC+11, Graham Dumpleton wrote: > > >> On 8 Jan 2018, at 6:16 pm, Shane nunya <[email protected] <>> wrote: >> >> Hi >> >> I've got a similar problem, that I'm not sure is covered by your blog post. >> >> I have got 3 possible domains, and one alias, everything was working fine, >> apache/mod_wsgi served the correct content for the appropriate URL. However, >> I decided to clever (which is what *always* leads to my downfall) and added >> HTTPS to one of my domains. In the process I had a problem where the ACME >> client provided by letsencrypt had issues caused by it copying the *80 >> virtual hosts verbatim, therefore creating several mod_wsgi instances (one >> for each vhost) with the same name. >> >> I found a SO post that suggested I switch to mod_wsgi as a global for the >> site, which fixed the issue, but now when I access one of the domains, the >> content from the default is loaded. >> >> So the problem URL is git.mydomain.com <http://git.mydomain.com/>, >> myotherdomain.nz <http://myotherdomain.nz/> is *fine*; I suspect because of >> the WSGIProcessGroup directive. >> >> As I type this out I am wondering if the solution is to go back to an >> individual mod_wsgi process per vhost, but name each one differently, eg. >> https_mydomain and http_mydomain > > You definitely want separate mod_wsgi daemon process group for each separate > site. > > This is necessary as: > > WSGIApplicationGroup %{GLOBAL} > > would cause everything to run in the same Python interpreter context of the > daemon processes. > > Some web frameworks can't handle mixing multiple sites in one interpreter, eg > Django, plus you will have other problems with different sites need different > versions of modules. > > So the pattern you want is: > > # Global stuff defined once. > > WSGIApplicationGroup %{GLOBAL} > WSGIRestrictEmbedded On > > # For first site. > > WSGIDaemonProcess mysite1 processes=2 threads=15 display-name=%{GROUP} > python-home=/var/www/vhosts/mydomain/site1-venv > > <VirtualHost *:80> > ServerName site1.com <http://site1.com/> > > WSGIScriptAlias / /some/path/site1/wsgi.py process-group=mysite1 > application-group=%{GLOBAL} > </VirtualHost> > > </VirtualHost *:443> > ServerName site1.com <http://site1.com/> > > WSGIScriptAlias / /some/path/site1/wsgi.py process-group=mysite1 > application-group=%{GLOBAL} > </VirtualHost> > > # For second site. > > WSGIDaemonProcess mysite2 processes=2 threads=15 display-name=%{GROUP} > python-home=/var/www/vhosts/mydomain/site2-venv > > <VirtualHost *:80> > ServerName site2.com <http://site1.com/> > > WSGIScriptAlias / /some/path/site2/wsgi.py process-group=mysite2 > application-group=%{GLOBAL} > </VirtualHost> > > </VirtualHost *:443> > ServerName site2.com <http://site1.com/> > > WSGIScriptAlias / /some/path/site2/wsgi.py process-group=mysite2 > application-group=%{GLOBAL} > </VirtualHost> > > >> >> ##### Apache Conf file ##### >> LogFormat "%v - %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" >> \"%{User-agent}i\"" combined-vhost >> WSGIApplicationGroup %{GLOBAL} >> WSGIRestrictEmbedded On >> WSGIScriptAlias / /var/www/vhosts/mydomain/mydomain/wsgi.py >> >> # adjust the following line to match your Python path >> WSGIDaemonProcess mydomain.com <http://mydomain.com/> processes=2 threads=15 >> display-name=%{GROUP} python-home=/var/www/vhosts/mydomain/venv/lib/python2.7 > > The value of python-home looks wrong. > > It should be the root of Python virtual environment, which is what sys.prefix > gives for interpreter. I would expect it to be > '/var/www/vhosts/mydomain/venv'. > > Not sure if that helps. > > Graham > >> WSGIProcessGroup mydomain.com <http://mydomain.com/> >> >> <VirtualHost *:80> >> ServerName www.mydomain.com <http://www.mydomain.com/> >> ServerAlias mydomain.com <http://mydomain.com/> >> DocumentRoot /var/www/vhosts/mydomain >> CustomLog /var/log/apache2/mydomain.log combined-vhost >> >> <directory /var/www/vhosts/mydomain> >> AllowOverride none >> Require all granted >> Options FollowSymlinks >> </directory> >> >> Alias /static/ /var/www/vhosts/mydomain/mydomain/static/ >> >> <Directory /var/www/vhosts/mydomain/mydomain/static> >> AllowOverride none >> Require all granted >> </Directory> >> </VirtualHost> >> <VirtualHost *:443> >> ServerName www.mydomain.com <http://www.mydomain.com/> >> ServerAlias mydomain.com <http://mydomain.com/> >> DocumentRoot /var/www/vhosts/mydomain >> CustomLog /var/log/apache2/mydomain_secure.log combined-vhost >> >> <directory /var/www/vhosts/mydomain> >> AllowOverride none >> Require all granted >> Options FollowSymlinks >> </directory> >> >> Alias /static/ /var/www/vhosts/mydomain/mydomain/static/ >> >> <Directory /var/www/vhosts/mydomain/mydomain/static> >> AllowOverride none >> Require all granted >> </Directory> >> Include /etc/letsencrypt/options-ssl-apache.conf >> SSLCertificateFile /etc/letsencrypt/live/myotherdomain.nz/fullchain.pem >> <http://myotherdomain.nz/fullchain.pem> >> SSLCertificateKeyFile /etc/letsencrypt/live/myotherdomain.nz/privkey.pem >> <http://myotherdomain.nz/privkey.pem> >> Include /etc/letsencrypt/options-ssl-apache.conf >> </VirtualHost> >> <VirtualHost *:80> >> ServerName git.mydomain.com <http://git.mydomain.com/> >> ServerAlias git.mydomain.com <http://git.mydomain.com/> >> DocumentRoot /home/shane/code_repository/public >> CustomLog /var/log/apache2/git.log combined-vhost >> <Directory /home/shane/code_repository/public> >> Options Indexes >> Require all granted >> AllowOverride none >> </Directory> >> </VirtualHost> >> ##### END ##### >> >> On Monday, August 14, 2017 at 10:43:18 AM UTC+10, Graham Dumpleton wrote: >> That would suggest you are using very old version of Apache 2.2. That >> directive is not required in Apache 2.4. >> >>> On 14 Aug 2017, at 1:30 am, rm...@ <>cornell.edu <http://cornell.edu/> >>> wrote: >>> >>> Actually I figured it out, my config was missing - >>> >>> NameVirtualHost *:80 >>> >>> After adding that, the virtual hosts are getting called correctly. >>> >>> Thanks and Cheers! >>> >>> On Sunday, August 13, 2017 at 12:16:21 AM UTC-4, [email protected] >>> <http://cornell.edu/> wrote: >>> Also, I checked the blog link below but that is a little different. Both >>> the URLs used in there end with the same domain address (e.g. example.com >>> <http://example.com/>). My case is a little different as both the URLs have >>> different domain addresses. Not sure if that matters? >>> >>> On Saturday, August 12, 2017 at 8:49:43 PM UTC-4, Graham Dumpleton wrote: >>> For general advice see: >>> >>> http://blog.dscpl.com.au/2012/10/requests-running-in-wrong-django.html >>> <http://blog.dscpl.com.au/2012/10/requests-running-in-wrong-django.html> >>> >>> See further comments below. >>> >>>> On 13 Aug 2017, at 9:45 am, <[email protected] <>> <[email protected] <>> >>>> wrote: >>>> >>>> Hello, >>>> >>>> I am trying to setup two virtual hosts pertaining to two websites - lets >>>> call them www.A.com <http://www.a.com/> and www.B.com <http://www.b.com/> >>>> using apache, mod_wsgi daemon. Both the apps are written using flask. >>>> >>>> Below is my apache conf file and for some reason it always picks the first >>>> declared virtual host URL and executes the first flask application for >>>> both URLs. >>> >>> What are the URLs you are using? >>> >>> Does the hostname in the URL match exactly what you are setting ServerName >>> to? >>> >>>> I am still new to the mod_wsgi scene and was reading multiple virtual >>>> hosts setup instructions from here - >>>> http://modwsgi.readthedocs.io/en/develop/user-guides/configuration-guidelines.html >>>> >>>> <http://modwsgi.readthedocs.io/en/develop/user-guides/configuration-guidelines.html> >>>> >>>> Any idea how to get both of them working? The apache server is run as root. >>>> >>>> Conf: >>>> WSGIPythonHome /usr/local/venvs/myenv >>>> >>>> <VirtualHost *:80> >>>> ServerName www.A.com <http://www.a.com/> >>>> >>>> WSGIDaemonProcess www.A.com <http://www.a.com/> threads=15 >>>> maximum-requests=10000 >>>> >>>> WSGIScriptAlias / /var/www/A/A.wsgi >>>> WSGIProcessGroup www.A.com <http://www.a.com/> >>>> >>>> <Directory /var/www/Ar> >>>> Order allow,deny >>>> Allow from all >>>> </Directory> >>>> >>>> </VirtualHost> >>>> >>>> <VirtualHost *:80> >>>> ServerName www.B.com <http://www.b.com/> >>>> >>>> WSGIDaemonProcess www.B.com <http://www.b.com/> threads=15 >>>> maximum-requests=10000 >>>> >>>> WSGIScriptAlias / /var/www/B/B.wsgi >>>> WSGIProcessGroup www.Bl.com <http://www.bl.com/> >>> >>> Do you mean www.B.com <http://www.b.com/> here. Not www.BI.com >>> <http://www.bi.com/>? >>> >>>> >>>> <Directory /var/www/B> >>>> Order allow,deny >>>> Allow from all >>>> </Directory> >>>> >>>> </VirtualHost> >>>> >>>> Thanks, >>>> RM >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "modwsgi" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to modwsgi+u...@ <>googlegroups.com <http://googlegroups.com/>. >>>> To post to this group, send email to mod...@ <>googlegroups.com >>>> <http://googlegroups.com/>. >>>> Visit this group at https://groups.google.com/group/modwsgi >>>> <https://groups.google.com/group/modwsgi>. >>>> For more options, visit https://groups.google.com/d/optout >>>> <https://groups.google.com/d/optout>. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "modwsgi" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected] <>. >>> To post to this group, send email to [email protected] <>. >>> Visit this group at https://groups.google.com/group/modwsgi >>> <https://groups.google.com/group/modwsgi>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <>. >> To post to this group, send email to [email protected] <>. >> Visit this group at https://groups.google.com/group/modwsgi >> <https://groups.google.com/group/modwsgi>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/576f2d22-eb3b-4275-b7e9-a367aa635f64n%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/576f2d22-eb3b-4275-b7e9-a367aa635f64n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/3059BAD4-F317-4CAF-8014-9D9891BCD3D9%40gmail.com.
