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]> wrote: > > Ok, so I followed the steps above, and lo and behold the site1.me > <http://site1.me/> worked! But my 2nd test site at site2.me > <http://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 <http://site1.me/> points to the > correct server IP on my mac's /etc/hosts file: 192.168.1.11 site1.me > <http://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://site2.me/> > HTTP_REFERER = > REQUEST_METHOD = GET > GATEWAY_INTERFACE = CGI/1.1 > PATH_TRANSLATED = > SERVER_NAME = site2.me <http://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 <http://site1.me/> > 192.168.1.11 site2.me <http://site2.me/> > and when visiting site2.me <http://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 >> <http://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 <[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 <http://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 <http://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 <http://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 <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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[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. For more options, visit https://groups.google.com/d/optout.
