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://site1.me/> http://site2.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 <[email protected]> wrote: > > Hmm I had the DaemonProcess correct just not in the above post, and I changed > the ServerName to site1.me <http://site1.me/> and site2.me > <http://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 >> <http://gmail.com/>> wrote: >> >> yeah my bad: >> >> <VirtualHost *:80> >> ServerName 192.168.1.10 >> ServerAlias site1.me <http://site1.me/> > > Only use: > > ServerName site1.me <http://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 <http://site2.me/> > > ServerName site2.me <http://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 <http://site1.me/> and > site2.me <http://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 >>> <http://gmail.com/>> 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] <>. >>> 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 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.
