Skip to content

Commit

Permalink
noweb2py in apache config
Browse files Browse the repository at this point in the history
  • Loading branch information
@snacktavish
snacktavish committed Apr 13, 2020
1 parent 7e40aaa commit 10debd6
Show file tree
Hide file tree
Showing 2 changed files with 1 addition and 22 deletions.
1 change: 1 addition & 0 deletions deploy/push.sh
View file
Original file line number Diff line number Diff line change
Expand Up @@ -240,6 +240,7 @@ function docomponent {
;;
otcetera)
push_otcetera || exit 1
restart_apache=yes
;;
*)
echo "Unrecognized component: $component"
Expand Down
22 changes: 0 additions & 22 deletions deploy/setup/opentree-ssl.conf
View file
Original file line number Diff line number Diff line change
Expand Up @@ -40,28 +40,6 @@
SSLOptions +StdEnvVars
</Directory>

# Moving all WSGI configuration here, so we only run one instance of web2py on HTTPS.
# This should prevent our broken session problem as documented here:
# https://github.com/OpenTreeOfLife/opentree/issues/804
WSGIDaemonProcess web2py user=phylesystemapi group=phylesystemapi display-name=%{GROUP}
WSGIProcessGroup web2py
WSGIScriptAlias / /home/phylesystemapi/web2py/wsgihandler.py

# We don't want the scriptalias to override mappings for
# treemachine and taxomachine... seems not to.

<Directory /home/phylesystemapi/web2py>
AllowOverride None
Require all denied
<Files wsgihandler.py>
Require all granted
</Files>
</Directory>

AliasMatch ^/([^/]+)/static/(.*) /home/phylesystemapi/web2py/applications/$1/static/$2
<Directory /home/phylesystemapi/web2py/applications/*/static/>
Require all granted
</Directory>

# OPENTREE SHARED CONFIGURATION
Include /etc/apache2/opentree-shared.conf
Expand Down

8 comments on commit 10debd6

@jimallman
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this change. Has WSGI configuration moved elsewhere, or was this redundant? Are we no longer running web2py via WSGI?

@snacktavish
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Jim - yeah I think reverting for updating this change likely makes sense. As we moved to different usernames on different machines, the paths in here were broken. e.g. /home/phylesystemapi/web2py/ vs /home/opentree/web2py/
Also I didn't want to be running web2py everywhere by default, as now most machines don't use web2py. But we need this section where we are using wbe2py. I wasn't sure if there were any concerns about leaving it in the config when we aren't using it. (other than the paths issue)

@jimallman
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure if there were any concerns about leaving it in the config when we aren't using it. (other than the paths issue)

Hmm. It does seem like this setup tries to capture all web traffic (/*) and route it to web2py:
WSGIScriptAlias / /home/phylesystemapi/web2py/wsgihandler.py

I suppose all our non-web2py services are able to respond because we're using RewriteRule abd ProxyPass to route to them.

Requests that don't match those patterns would fall through to web2py by default, which is not so bad I think. On a server that's not running web2py, these will produce an apache error, but I don't think that's any worse then a web2py error. Neither is going to be very friendly or informative. 😬

@jimallman
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the paths in here were broken. e.g. /home/phylesystemapi/web2py/

Oh, I missed this bit. Does this just trigger a warning from apache, or is it a show-stopper for deployment? If the latter, we'll need to come up with a test (during deployment) to see whether this particular server uses web2py, an omit this section if not.

@snacktavish
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah - apache won't start up if the wrong paths are in there, so a bit more dynamic configuration is needed on deployment. It might actually not be the path... but the existence of the user itself.

@jimallman
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. I'll look into adding a switch for this, based on the component(s) being deployed.

@jimallman
Copy link
Member

@jimallman jimallman commented on 10debd6 May 2, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One interesting wrinkle so far... The switch (var $installing_web2py alongside $restart_apache) is normally set based on the component(s) being deployed, but we have a component apache that rebuilds the apache config before restarting apache. By default, this won't recognize whether we're using web2py, so it will have the effect of removing the web2py-related apache configuration. I see a couple of options:

  1. Since the apache command is pretty much a convenience option to push.sh, maybe we can just drop it? I think at this point most of us are using more direct options like ssh admin@ot20 'sudo apache2ctl graceful'.

  2. or we could add one more flag ($update_apache_config=yes) that's set to no for the apache command, so that is leaves everything in place and simply restarts apache. Thoughts?

EDIT: This is one of those things that, as I wrote it, the solution seems clear enough. I'm going ahead with option (2) above, but of course opinions are welcome.

@snacktavish
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like a plan!

Please sign in to comment.