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] <javascript:>> > 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] <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.
