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*<num of
cpu cores>).
And upgrade whenever possible, since web2py is now faster and more secure...

mic


2013/11/1 AbrahamLinksys <[email protected]>

> 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.privat**e.key
>>
>>   <Location /admin>
>>    Deny from all
>>  </Location>
>>
>>   *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
>>  <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.privat**e.key
>>
>>   <Location /admin>
>>    Deny from all
>>  </Location>
>>
>> *  WSGIProcessGroup web2py-ssl*
>>   WSGIScriptAlias / /var/www/web2py/wsgihandler.py
>>
>>   Alias /css/ /var/www/web2py/applications/a**pp2/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.
>

-- 
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.

Reply via email to