Re: [web2py] Re: Internal Error - Ticket unknown - only over HTTPS?!
Great you found the problem and the solution! You should not need 777
permissions though. Just set the owner and/or the group of your web2py app
dir to the same user as the apache user (web-user as I see in your mail).
As a side note I see you use
WSGIDaemonProcess web2py user=web-user group=web-user threads=15
display-name=%{GROUP}
If you want better performance remove threads and put processes=(2*).
And upgrade whenever possible, since web2py is now faster and more secure...
mic
2013/11/1 AbrahamLinksys
> 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):
>>
>>
>> ...
>> WSGIDaemonProcess web2py user=web-user group=web-user threads=15
>> display-name=%{GROUP}
>> WSGIDaemonProcess web2py
>> ...
>>
>>
>>
>> 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
>>
>> ServerName app1.domain.edu
>>
>> SSLEngine on
>> SSLCertificateFile /etc/pki/tls/certs/app1.domain**.edu.crt
>> SSLCertificateKeyFile /etc/ssl/private/server.privat**e.key
>>
>>
>>Deny from all
>>
>>
>> *WSGIProcessGroup web2py-ssl*
>> WSGIScriptAlias / /var/www/web2py/wsgihandler.py
>>
>> Alias /css/ /var/www/web2py/applications/a**pp1/static/
>> AliasMatch ^/([^/]+)/static/(.*) \
>> /var/www/web2py/applications/$**1/static/$2
>>
>>Order Allow,Deny
>>Allow from all
>>
>>
>>
>>
>> ServerName app2.domain.edu
>>
>> SSLEngine on
>> SSLCertificateFile /etc/pki/tls/certs/app2.domain**.edu.crt
>> SSLCertificateKeyFile /etc/ssl/private/server.privat**e.key
>>
>>
>>Deny from all
>>
>>
>> * WSGIProcessGroup web2py-ssl*
>> WSGIScriptAlias / /var/www/web2py/wsgihandler.py
>>
>> Alias /css/ /var/www/web2py/applications/a**pp2/static/
>> AliasMatch ^/([^/]+)/static/(.*) \
>> /var/www/web2
[web2py] Re: Internal Error - Ticket unknown - only over HTTPS?!
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):
>
>
> ...
> WSGIDaemonProcess web2py user=web-user group=web-user threads=15
> display-name=%{GROUP}
> WSGIDaemonProcess web2py
> ...
>
>
>
> 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
>
> ServerName app1.domain.edu
>
> SSLEngine on
> SSLCertificateFile /etc/pki/tls/certs/app1.domain.edu.crt
> SSLCertificateKeyFile /etc/ssl/private/server.private.key
>
>
>Deny from all
>
>
> *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
>
>Order Allow,Deny
>Allow from all
>
>
>
>
> ServerName app2.domain.edu
>
> SSLEngine on
> SSLCertificateFile /etc/pki/tls/certs/app2.domain.edu.crt
> SSLCertificateKeyFile /etc/ssl/private/server.private.key
>
>
>Deny from all
>
>
> * 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
>
>Order Allow,Deny
>Allow from all
>
>
>
>
> 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
[web2py] Re: Internal Error - Ticket unknown - only over HTTPS?!
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):
...
WSGIDaemonProcess web2py user=web-user group=web-user threads=15
display-name=%{GROUP}
WSGIDaemonProcess web2py
...
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
ServerName app1.domain.edu
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/app1.domain.edu.crt
SSLCertificateKeyFile /etc/ssl/private/server.private.key
Deny from all
*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
Order Allow,Deny
Allow from all
ServerName app2.domain.edu
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/app2.domain.edu.crt
SSLCertificateKeyFile /etc/ssl/private/server.private.key
Deny from all
* 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
Order Allow,Deny
Allow from all
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 cer
