yeah my bad:
<VirtualHost *:80>
ServerName 192.168.1.10
ServerAlias site1.me
ServerAdmin [email protected]
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
ServerAdmin [email protected]
WSGIDaemonProcess site1
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>
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 <[email protected] <javascript:>>
> 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 <[email protected]> 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 <[email protected]> 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 [email protected].
>> To post to this group, send email to [email protected].
>> 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 [email protected] <javascript:>.
> To post to this group, send email to [email protected] <javascript:>
> .
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
