I meant to use: http://site1.me <http://site1.me/> http://site2.me <http://site2.me/>
in the browser when making the request, not in ServerName. ServerName should be just the hostname. Are their symlinks in the sites-enabled directory to the files in the sites-available directory? Just because they are in sites-available doesn’t mean Apache will read them. On your Linux distro the sites have to be enabled, using s2enable, which results in a symlink being put in sites-enabled to same site in sites-available. Graham > On 23 Sep 2016, at 10:02 PM, Jaqen Nki <projan...@gmail.com> wrote: > > Heres > > /etc/apache2/sites-available$ ls > 000-default.conf default-ssl.conf site1.conf site2.conf > > > config files: > > etchost: > > ## > # Host Database > # > # localhost is used to configure the loopback interface > # when the system is booting. Do not change this entry. > ## > 127.0.0.1 localhost > 255.255.255.255 broadcasthost > ::1 localhost > > > 192.168.1.10 site1.me <http://site1.me/> http://site1.me > <http://site1.me/> > 192.168.1.10 site2.me <http://site2.me/> http://site2.me > <http://site2.me/> > > > > <VirtualHost *:80> > ServerName http://site1.me <http://site1.me/> > ServerAdmin ad...@mywebsite.com <mailto:ad...@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 http://site2.me <http://site2.me/> > ServerAdmin ad...@mywebsite.com <mailto:ad...@mywebsite.com> > > WSGIDaemonProcess site2 > 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> > > > cat /etc/apache2/mods-available/wsgi.load > > LoadModule wsgi_module > /usr/lib/apache2/modules/mod_wsgi-py35.cpython-35m-x86_64-linux-gnu.so > WSGIRestrictEmbedded On > > Im now getting 500 error at site2.me <http://site2.me/>. site1 still works. > > > > > On Friday, September 23, 2016 at 4:40:07 AM UTC-7, Graham Dumpleton wrote: > 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 <proj...@ <>gmail.com >> <http://gmail.com/>> 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 <proj...@gmail.com <>> 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 modwsgi+u...@googlegroups.com <>. >>>> To post to this group, send email to mod...@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 modwsgi+u...@googlegroups.com <>. >>> To post to this group, send email to mod...@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 sub > > > -- > 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+unsubscr...@googlegroups.com > <mailto:modwsgi+unsubscr...@googlegroups.com>. > To post to this group, send email to modwsgi@googlegroups.com > <mailto:modwsgi@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 modwsgi+unsubscr...@googlegroups.com. To post to this group, send email to modwsgi@googlegroups.com. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
