Also -- I'm pretty sure all the tickets turned to unknown/unrecoverable
because the errors directory was also unwritable, hence the inability to
see the actual error messages (which probably referred to the database most
of the time... )
So a good way to check for that early on when receiving strange errors like
that is to chmod the errors directory:
chmod 777 /path/to/web2py/applications/app/errors
But probably best not to leave it that way.
On Friday, November 1, 2013 3:44:30 PM UTC-5, AbrahamLinksys wrote:
>
> Hi Michele,
>
> Thanks for your response. I actually managed to solve it.
>
> To review, thanks for the idea of looking at tickets -- unfortunately,
> part of the issue was that tickets were not being written for these errors,
> thus there is nothing to unpickle :(
>
> So, since the app was not generating errors when running over WSGI with
> HTTP, so I THOUGHT that the error WAS at the web2py or wsgi level.
>
> But when I started logging things (good suggestion by the way; I'd never
> really had luck with web2py logging, but I finally figured it out!)
> I found my models weren't loading past the auth define tables call. Turns
> out some sort of migration was trying to happen, as setting migrate=False
> in auth.define_tables() call fixed that, even though I had fake_migrate_all
> set in the DAL definition (it didn't seem to care... probably it was a
> permissions issue on the databases folder, but I copied metadata files from
> the dev server and that seemed to fix it).
>
> But I still had other issues related to my login pages and most pages with
> DB access and some forms using session, still only over https. Anyway,
> after the "unkown ticket" issue went away, these pages would generate an
> "unrecoverable" ticket error (still not writing any ticket).
>
> After stumbling around on this list, i found someone who had seen many
> people have the unrecoverable ticket, but that his problem and solution was
> generally different than theirs -- he had a permissions issue. I had
> already verified the web user was running web2py and had proper
> permissions, but I did a chmod 777 on the sessions directory anyway (that
> means fully open permissions fyi) and voila!
>
> That solved all my issues! Because of the way I had configured mod_wsgi,
> the HTTPS instances were running under the user "apache" (as defined by
> default in httpd.conf), whereas the HTTP instances were running as the
> "web" user because they had a WSGIProcess
>
> It didn't seem to like me adding "WSGIProcessGroup web2py" to the SSL
> VirtualHost sections, so I defined a separate processgroup for the SSL
> instances . Maybe the thing to do is to put the original WSGIDaemonProcess
> declaration outside all the Vhosts and use the same web2py process group
> for all VHosts, but it's working this way, so this is the way it shall
> work.
>
> Anyway, this eliminated all the permissions errors because now it's
> running properly as the "web" user over SSL and can function as intended.
>
> So the new apache config file for SSL looks like this (changes in
> bold/italic):
>
> <VirtualHost *:80>
> ...
> WSGIDaemonProcess web2py user=web-user group=web-user threads=15
> display-name=%{GROUP}
> WSGIDaemonProcess web2py
> ...
> </VirtualHost>
>
>
> LoadModule ssl_module modules/mod_ssl.so
>
> *WSGIDaemonProcess web2py-ssl user=web-user group=web-user threads=15
> display-name=%{GROUP}*
>
> Listen 443
> NameVirtualHost *:443
> <VirtualHost *:443>
> ServerName app1.domain.edu
>
> SSLEngine on
> SSLCertificateFile /etc/pki/tls/certs/app1.domain.edu.crt
> SSLCertificateKeyFile /etc/ssl/private/server.private.key
>
> <Location /admin>
> Deny from all
> </Location>
>
> *WSGIProcessGroup web2py-ssl*
> WSGIScriptAlias / /var/www/web2py/wsgihandler.py
>
> Alias /css/ /var/www/web2py/applications/app1/static/
> AliasMatch ^/([^/]+)/static/(.*) \
> /var/www/web2py/applications/$1/static/$2
> <Directory /var/www/web2py/applications/*/static/*/>
> Order Allow,Deny
> Allow from all
> </Directory>
> <VirtualHost>
>
> <VirtualHost *:443>
> ServerName app2.domain.edu
>
> SSLEngine on
> SSLCertificateFile /etc/pki/tls/certs/app2.domain.edu.crt
> SSLCertificateKeyFile /etc/ssl/private/server.private.key
>
> <Location /admin>
> Deny from all
> </Location>
>
> * WSGIProcessGroup web2py-ssl*
> WSGIScriptAlias / /var/www/web2py/wsgihandler.py
>
> Alias /css/ /var/www/web2py/applications/app2/static/
> AliasMatch ^/([^/]+)/static/(.*) \
> /var/www/web2py/applications/$1/static/$2
> <Directory /var/www/web2py/applications/*/static/*/>
> Order Allow,Deny
> Allow from all
> </Directory>
> <VirtualHost>
>
>
> And now the permissions aren't an issue and we don't have any
> login/sessions/forms issues.
>
> :D
>
>
>
>
>
>
>
>
>
> import logging
> logger = logging.getLogger("web2py.app.app2")
> logger.setLevel(logging.DEBUG)
>
>
> logger.info("HERE")
>
> On Wednesday, October 30, 2013 12:49:28 PM UTC-5, AbrahamLinksys wrote:
>>
>> Hi all,
>>
>> I'm running a little older version of web2py in production (1.99.7).
>>
>> I have two apps configured to different subdomains --
>> app1.domain.edu -> app1
>> app2.domain.edu -> app2
>>
>> This works fine. Great in fact -- I'm using routers to make the apps
>> default based on the domain, so appnames aren't needed.
>>
>> Recently we decided to add authenticated services to the applications, so
>> I got some certificates and set up web2py over SSL.
>>
>> So over https, app1 works fine but app2 generates the unknown ticket
>> issue.
>>
>> This doesn't appear to be any sort of permissions or storage issue (lots
>> of room/inodes on disk, errors dir writable by app2 when requested over
>> HTTP -- doesn't normally generate an error over HTTP, I could 777 the
>> errors dir but I can't see how that would be an issue).
>>
>> Also, on the test server (where I run rocket) both sites run fine over
>> HTTPS, albeit with cert warnings because of my self-signed test certs.
>> There I have an two web2py daemons -- one for HTTP and one for HTTPS
>> running on two different ports, using apache with mod_proxy to dispatch
>> requests based on the hostname.
>>
>>
>> Does anyone have any ideas? I'm thinking it's might be related to the
>> "routers" feature ... or maybe somehow app1's directories or models are
>> getting loaded when requesting app2? I'm not even really sure how to
>> diagnose the issue as I don't see any logs to read (though I haven't ever
>> used web2py's logging, perhaps that would help?)
>>
>>
>> Also -- and I doubt this is an issue but I'll just throw it out there --
>> I used the same private key to generate CSRs for both SSL certificates for
>> the two FQDNs -- is it possible that WSGI doesn't like this? As far as I
>> know this is accepted when generating SSL certs. And I don't get any
>> certificate issues when using the two domains.. and when just serving HTML
>> from the filesystem w/apache everything is fine.
>>
>>
>> If I don't make progress I will probably try to upgrade to the newest
>> version of web2py and see if the issue persists... however any help is
>> appreciated!
>>
>>
>> Here are some relevant snippets from config files:
>>
>> /var/www/web2py/routes.py
>>
>> routers = dict(
>> BASE = dict(
>> domains = {
>> 'app1.domain.edu': 'app1',
>> 'www.app1.domain.edu': 'app1',
>> 'app2.domain.edu': 'app2',
>> 'www.app2.domain.edu': 'app2',
>> 'www.app2.domain.edu:443': 'app2/default' # I added this after
>> getting the error, it doesn't seem to affect it. It's not currently in my
>> routes file, still getting error.
>> }
>> ),
>> )
>>
>>
>> apache conf:
>>
>> NameVirtualHost *:80
>>
>> <Directory /var/www/web2py>
>> AllowOverride None
>> Order Allow,Deny
>> Deny from all
>> <Files wsgihandler.py>
>> Allow from all
>> </Files>
>> </Directory>
>>
>> WSGISocketPrefix /var/run/wsgi/
>> <Virtualhost *:80>
>> ServerName app1.domain.edu
>> ServerAlias app2.domain.edu
>>
>> WSGIDaemonProcess web2py user=webadmin group=webadmin threads=15 \
>> display-name=%{GROUP}
>> WSGIProcessGroup web2py
>> WSGIApplicationGroup %{RESOURCE}
>>
>> # This routes all requests that aren't user-dir or awstats requests to
>> web2py
>> WSGIScriptAliasMatch ^(/([^~].*|awstats.*)?)$
>> /var/www/web2py/wsgihandler.py$1
>>
>> # ... mod_user stuff that I won't bother copying is here (for tilde
>> sites) ... #
>>
>> Alias /css/ /var/www/web2py/applications/app1/static/
>>
>> AliasMatch ^/([^/]+)/static/(.*) \
>> /var/www/web2py/applications/$1/static/$2
>> <Directory /var/www/web2py/applications/*/static/*/>
>> Order Allow,Deny
>> Allow from all
>> </Directory>
>> </VirtualHost>
>>
>>
>>
>> LoadModule ssl_module modules/mod_ssl.so
>>
>> Listen 443
>> NameVirtualHost *:443
>> <VirtualHost *:443>
>> ServerName app1.domain.edu
>>
>> SSLEngine on
>> SSLCertificateFile /etc/pki/tls/certs/app1.domain.edu.crt
>> SSLCertificateKeyFile /etc/ssl/private/server.private.key
>>
>> <Location /admin>
>> Deny from all
>> </Location>
>>
>> WSGIScriptAlias / /var/www/web2py/wsgihandler.py
>>
>> Alias /css/ /var/www/web2py/applications/app1/static/
>> AliasMatch ^/([^/]+)/static/(.*) \
>> /var/www/web2py/applications/$1/static/$2
>> <Directory /var/www/web2py/applications/*/static/*/>
>> Order Allow,Deny
>> Allow from all
>> </Directory>
>> <VirtualHost>
>>
>> <VirtualHost *:443>
>> ServerName app2.domain.edu
>>
>> SSLEngine on
>> SSLCertificateFile /etc/pki/tls/certs/app2.domain.edu.crt
>> SSLCertificateKeyFile /etc/ssl/private/server.private.key
>>
>> <Location /admin>
>> Deny from all
>> </Location>
>>
>> WSGIScriptAlias / /var/www/web2py/wsgihandler.py
>>
>> Alias /css/ /var/www/web2py/applications/app2/static/
>> AliasMatch ^/([^/]+)/static/(.*) \
>> /var/www/web2py/applications/$1/static/$2
>> <Directory /var/www/web2py/applications/*/static/*/>
>> Order Allow,Deny
>> Allow from all
>> </Directory>
>> <VirtualHost>
>>
>>
>>
>>
>>
>>
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
