Heres

/etc/apache2/sites-available$ ls
000-default.conf  default-ssl.conf  site1.conf  site2.conf


config files:

etchost:

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost


192.168.1.10    site1.me        http://site1.me
192.168.1.10    site2.me        http://site2.me



<VirtualHost *:80>
                ServerName http://site1.me
                ServerAdmin ad...@mywebsite.com

                WSGIDaemonProcess site1 
python-home=/var/www/site1/FlaskApp/FlaskApp/venv
                WSGIProcessGroup site1
                WSGIApplicationGroup %{GLOBAL}
                WSGIScriptAlias / /var/www/site1/FlaskApp/flaskapp.wsgi
                <Directory /var/www/site1/FlaskApp/FlaskApp/>
                        Order allow,deny
                        Allow from all
                </Directory>
                Alias /static /var/www/site1/FlaskApp/FlaskApp/static
                <Directory /var/www/site1/FlaskApp/FlaskApp/static/>
                        Order allow,deny
                        Allow from all
                </Directory>
                ErrorLog /var/www/site1/logs/error.log
                LogLevel warn
                CustomLog /var/www/site1/logs/access.log combined
</VirtualHost>


<VirtualHost *:80>
                ServerName http://site2.me
                ServerAdmin ad...@mywebsite.com

                WSGIDaemonProcess site2 
python-home=/var/www/site2/FlaskApp/FlaskApp/venv
                WSGIProcessGroup site2
                WSGIApplicationGroup %{GLOBAL}
                WSGIScriptAlias / /var/www/site2/FlaskApp/flaskapp.wsgi
                <Directory /var/www/site2/FlaskApp/FlaskApp/>
                        Order allow,deny
                        Allow from all
                </Directory>
                Alias /static /var/www/site2/FlaskApp/FlaskApp/static
                <Directory /var/www/site2/FlaskApp/FlaskApp/static/>
                        Order allow,deny
                        Allow from all
                </Directory>
                ErrorLog /var/www/site2/logs/error.log
                LogLevel warn
                CustomLog /var/www/site2/logs/access.log combined
</VirtualHost>


cat /etc/apache2/mods-available/wsgi.load

LoadModule wsgi_module 
/usr/lib/apache2/modules/mod_wsgi-py35.cpython-35m-x86_64-linux-gnu.so
WSGIRestrictEmbedded On

Im now getting 500 error at site2.me.  site1 still works.




On Friday, September 23, 2016 at 4:40:07 AM UTC-7, Graham Dumpleton wrote:
>
> If you have it with ServerName as I suggest, and there ate /etc/hosts 
> entries mapping the host names to the local system IP, then using:
>
> http://site1.me
> http://site2.me
>
> should result in them going to the correct VirtualHost and being handled 
> by respective applications.
>
> If they aren’t it would suggest the VirtualHost’s aren’t being read by 
> Apache.
>
> What file are they in?
>
> If you put a syntax error in the VirtualHost definitions, does Apache fail 
> to start.
>
> Just add a line with:
>
>    xxxx
>
> and it should fail.
>
> Graham
>
> On 23 Sep 2016, at 9:33 PM, Jaqen Nki <proj...@gmail.com <javascript:>> 
> wrote:
>
> Hmm I had the DaemonProcess correct just not in the above post, and I 
> changed the ServerName to site1.me and site2.me, the etc/hosts file has 
> them both at 192.168.1.10.  Not sure if/how to resolve the DNS figured that 
> was automatic.  My network settings say using DHCP, and I use openDNS.  
> Would I have to add other DNS entries for each vhost?
>
> On Friday, September 23, 2016 at 4:11:24 AM UTC-7, Graham Dumpleton wrote:
>>
>>
>> On 23 Sep 2016, at 9:07 PM, Jaqen Nki <proj...@gmail.com> wrote:
>>
>> yeah my bad:
>>
>> <VirtualHost *:80>
>>                 ServerName 192.168.1.10
>>                 ServerAlias site1.me
>>
>>
>> Only use:
>>
>> ServerName site1.me
>>
>> Don’t use ServerAlias and don’t use the IP.
>>
>>                 ServerAdmin ad...@mywebsite. <http://mywebsite.com/>com 
>> <http://mywebsite.com/>
>>
>>                 WSGIDaemonProcess site1 
>> python-home=/var/www/site1/FlaskApp/FlaskApp/venv
>>                 WSGIProcessGroup site1
>>                 WSGIApplicationGroup %{GLOBAL}
>>                 WSGIScriptAlias / /var/www/site1/FlaskApp/flaskapp.wsgi
>>                 <Directory /var/www/site1/FlaskApp/FlaskApp/>
>>                         Order allow,deny
>>                         Allow from all
>>                 </Directory>
>>                 Alias /static /var/www/site1/FlaskApp/FlaskApp/static
>>                 <Directory /var/www/site1/FlaskApp/FlaskApp/static/>
>>                         Order allow,deny
>>                         Allow from all
>>                 </Directory>
>>                 ErrorLog /var/www/site1/logs/error.log
>>                 LogLevel warn
>>                 CustomLog /var/www/site1/logs/access.log combined
>> </VirtualHost>
>>
>> <VirtualHost *:80>
>>                 ServerName 192.168.1.10
>>                 ServerAlias site2.me
>>
>>
>> ServerName site2.me
>>
>>                 ServerAdmin ad...@mywebsite. <http://mywebsite.com/>com 
>> <http://mywebsite.com/>
>>
>>                 WSGIDaemonProcess site1 
>> python-home=/var/www/site2/FlaskApp/FlaskApp/venv
>>
>>
>> This should be:
>>
>>      WSGIDaemonProcess site2 
>> python-home=/var/www/site2/FlaskApp/FlaskApp/venv
>>
>> The server shouldn’t even have started with what you had as site1 name 
>> already used and should have complained about duplicate. Are you sure both 
>> were being read.
>>
>> Also, do you actually have resolvable DNS for site1.me and site2.me, or 
>> entries for them in /etc/hosts. Name based virtual hosts will not work 
>> without.
>>
>> Graham
>>
>>                 WSGIProcessGroup site2
>>                 WSGIApplicationGroup %{GLOBAL}
>>                 WSGIScriptAlias / /var/www/site2/FlaskApp/flaskapp.wsgi
>>                 <Directory /var/www/site2/FlaskApp/FlaskApp/>
>>                         Order allow,deny
>>                         Allow from all
>>                 </Directory>
>>                 Alias /static /var/www/site2/FlaskApp/FlaskApp/static
>>                 <Directory /var/www/site2/FlaskApp/FlaskApp/static/>
>>                         Order allow,deny
>>                         Allow from all
>>                 </Directory>
>>                 ErrorLog /var/www/site2/logs/error.log
>>                 LogLevel warn
>>                 CustomLog /var/www/site2/logs/access.log combined
>> </VirtualHost>
>>
>>
>> On Friday, September 23, 2016 at 2:28:01 AM UTC-7, Graham Dumpleton wrote:
>>>
>>> Can you post the two VirtualHost configurations?
>>>
>>> The IP address should not be mentioned in the VirtualHost definition 
>>> anywhere normally. So shouldn’t have IP in ServerName either.
>>>
>>> Graham
>>>
>>> On 23 Sep 2016, at 5:46 PM, Jaqen Nki <proj...@gmail.com> wrote:
>>>
>>> Ok, so I followed the steps above, and lo and behold the site1.me worked!  
>>> But my 2nd test site at site2.me did not.  (What I did was duplicate my 
>>> site1 project as site2, changed all the conf files and gave it a new 
>>> database to reflect the change.  I think theres some conflict as both vhost 
>>> configs are trying to share the same local IP.  I noticed in the vhost file 
>>> the ServerName has an incorrect IP address (192.168.1.7) for the ubuntu 
>>> server but it doesnt affect anything since the ServerAlias site1.me points 
>>> to the correct server IP on my mac's /etc/hosts file:  192.168.1.11   
>>> site1.me.)  I got this info upon visiting that domain : 
>>>
>>> (0)REMOTE_ADDR = 206.127.117.221
>>> REMOTE_PORT = 11233
>>> HTTP_USER_AGENT = Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) 
>>> Gecko/20100101 Firefox/48.0
>>> HTTP_ACCEPT = 
>>> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>>> HTTP_ACCEPT_CHARSET = 
>>> HTTP_CONNECTION = keep-alive
>>> HTTP_HOST = site2.me
>>> HTTP_REFERER = 
>>> REQUEST_METHOD = GET
>>> GATEWAY_INTERFACE = CGI/1.1
>>> PATH_TRANSLATED = 
>>> SERVER_NAME = site2.me
>>> SERVER_ADDR = 192.168.5.5
>>> 2016-09-23 10:29:04
>>>
>>> After which I tested copying the same line in /etc/hosts on mac, 
>>> 192.168.1.11 site1.me
>>> 192.168.1.11 site2.me
>>> and when visiting site2.me in browser I actually got the Apache2 Ubuntu 
>>> Default - It Works! page, so Im close but theres some conflict with an IP 
>>> or hostname it seems.  
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wednesday, September 21, 2016 at 7:06:05 PM UTC-7, Graham Dumpleton 
>>> wrote:
>>>>
>>>> If the intention is still to try and do it yourself with one Apache 
>>>> instance, the description given before is still valid.
>>>>
>>>> So not sure I have anything more to add at this point. Personally I am 
>>>> a fan of PaaS, but cost can be a concern with those.
>>>>
>>>> Can perhaps go more into it when you start progressing more with the 
>>>> setup.
>>>>
>>>> Graham 
>>>>
>>>> On 21 Sep 2016, at 3:57 PM, Jaqen Nki <proj...@gmail.com> wrote:
>>>>
>>>> Hey Graham, been awhile.  Glad I could help ya out with that amzn 
>>>> gift.  Got busy doing other crap and on road trips this summer so took a 
>>>> break from programming.  Also hit a wall with flask where it became 
>>>> difficult to build a dynamic user dashboard system so got discouraged.  I 
>>>> like flask but Im finding its extensibility and total freedom to craft 
>>>> your 
>>>> own web app to be a double edged sword.  I may use it for simple static 
>>>> sites but for more complexity I may have to abandon it because it feels 
>>>> like the things I want to do become too convoluted and require skill on 
>>>> the 
>>>> level of a web/software engineer.  Not sure why I would reinvent the 
>>>> proverbial 'wheel' when at my level it will be inferior and may be 
>>>> bottlenecked or have security breaches Im unaware of when someone at a 
>>>> much 
>>>> higher level has built something much better.  Not only that, to manually 
>>>> edit every sql query, every init.py change, every html change is going to 
>>>> be a logistical nightmare if Im managing like 20 websites.  So Im knocking 
>>>> out a good django series and I like how its structured, more split up, 
>>>> easier to manage via admin panel, apps can be reused etc.  I hope its 
>>>> going 
>>>> to solve some of these logistical and efficiency issues as far as building 
>>>> and managing websites.  My short term goal is to build sites like a blog 
>>>> with commenting system, a forum, dynamic user dashboard, and later on a 
>>>> basic ecommerce store, and to be able to manage these sites easier via 
>>>> django admin (or partially hand the reins to the site owner for basic 
>>>> content posting/editing).   That way my time is freed up from doing menial 
>>>> edits and whatnot for client's sites.  I hope django can be my answer to 
>>>> these dilemmas.
>>>>
>>>> Anyways I was curious if you have experience / advice in this area, and 
>>>> currently Im revisiting how to properly set up numerous projects each with 
>>>> their own separate virtual environment, as we previously discussed below.  
>>>> I plan on using this local ubuntu VM as my local dev server, hosting all 
>>>> my 
>>>> projects (5-10 short term, 20-50+ eventually) and then uploading them to 
>>>> digital ocean for production.  All I need at the moment is to set up a few 
>>>> projects and make sure their virtualenvs are separate but sharing the same 
>>>> IP.  Thanks.
>>>>
>>>>
>>>> **********
>>>> On 12 May 2016, at 6:32 PM, Jaqen Nki <proj...@gmail.com> wrote: 
>>>> So I take it for a new project, I repeat the process, new vhost and 
>>>> .wsgi file, and create a wsgi.load file for each site? 
>>>>
>>>> The wsgi.load file should only have in it the LoadModule, 
>>>> WSGIPythonHome and WSGIRestrictEmbedded directives. They applied to the 
>>>> server as a whole and not specific VirtualHosts. 
>>>>
>>>> When you talk about adding more VirtualHost’s, that is when you will 
>>>> need to be a bit careful with respect to virtual environments. 
>>>>
>>>> First up, a separate VirtualHost is used for each distinct site 
>>>> hostname. Don’t use separate VirtualHost’s if only trying to mount 
>>>> different applications at different sub URLs of the same site. Seen people 
>>>> try and use multiple VirtualHost’s for same site hostname too many times. 
>>>> Is wrong way. 
>>>>
>>>> Because you are going to have multiple VirtualHost’s would suggest 
>>>> doing things a little differently. 
>>>>
>>>> First up, the wsgi.load file would only have LoadModule and 
>>>> WSGIRestrictEmbedded directives in it. Not WSGIPythonHome. 
>>>>
>>>> In that file the WSGIPythonHome was acting as a fallback for both 
>>>> embedded mode and daemon mode. With WSGIRestrictEmbedded set to On, don’t 
>>>> need the fallback. Instead, we want to set python-home for each daemon 
>>>> process group setup using WSGIDaemonProcess directive. 
>>>>
>>>> Thus: 
>>>>
>>>> # wsgi.load 
>>>>
>>>> LoadModule … 
>>>> WSGIRestrictEmbedded On 
>>>>
>>>> # site1.conf 
>>>>
>>>> <VirtualHost *:80> 
>>>> ServerName site1.host.name 
>>>>
>>>> WSGIDaemonProcess site1 python-home=/some/path/site1/
>>>> venv 
>>>> WSGIProcessGroup site1 
>>>> WSGIApplicationGroup %{GLOBAL} 
>>>>
>>>> WSGIScriptAlias / /some/path/site1/app.wsgi 
>>>>
>>>> ... 
>>>> </VirtualHost> 
>>>>
>>>> # site2.conf 
>>>>
>>>> <VirtualHost *:80> 
>>>> ServerName site2.host.name 
>>>>
>>>> WSGIDaemonProcess site2 python-home=/some/path/site2/venv 
>>>> WSGIProcessGroup site2 
>>>> WSGIApplicationGroup %{GLOBAL} 
>>>>
>>>> WSGIScriptAlias / /some/path/site1/app.wsgi 
>>>>
>>>> ... 
>>>> </VirtualHost> 
>>>>
>>>> If you do need to host multiple applications under same VirtualHost at 
>>>> different sub URLs, you would use something like: 
>>>>
>>>> # site3.conf 
>>>>
>>>> <VirtualHost *:80> 
>>>> ServerName site3.host.name 
>>>>
>>>> WSGIDaemonProcess site3_main python-home=/some/path/site3_main/venv 
>>>> WSGIDaemonProcess site3_suburl python-home=/some/path/site3_suburl/venv
>>>>  
>>>>
>>>> WSGIProcessGroup site3 
>>>> WSGIApplicationGroup %{GLOBAL} 
>>>>
>>>> WSGIScriptAlias /suburl /some/path/site3_suburl/app.wsgi 
>>>> process-group=site3_suburl 
>>>> WSGIScriptAlias / /some/path/site3_main/app.wsgi 
>>>>
>>>> ... 
>>>> </VirtualHost>
>>>> **********
>>>>
>>>> -- 
>>>> 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.
>>>> To post to this group, send email to mod...@googlegroups.com.
>>>> Visit this group at https://groups.google.com/group/modwsgi.
>>>> For more options, visit 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 modwsgi+u...@googlegroups.com.
>>> To post to this group, send email to mod...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/modwsgi.
>>> For more options, visit 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 modwsgi+u...@googlegroups.com.
>> To post to this group, send email to mod...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/modwsgi.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
> -- 
> You received this message because you are sub
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to modwsgi@googlegroups.com.
Visit this group at https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to