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