Here is the current production.ini file # # myapp - TurboGears configuration # # The %(here)s variable will be replaced with the parent directory of this file # [DEFAULT] # WARGING == If debug is not set to false, you'll get the interactive # debugger on production, which is a huge security hole.
debug = false email_to = [email protected] smtp_server = localhost error_email_from = pa...@localhost [server:main] use = egg:Paste#http host = 0.0.0.0 port = 8080 [app:main] use = egg:myapp full_stack = true cache_dir = %(here)s/data beaker.session.key = myapp beaker.session.secret = xHYOM6ne9tap4VP4fVaucg4Nc app_instance_uuid = {e120e38b-26fc-4856-b130-7b6bb0a5c579} # If you'd like to fine-tune the individual locations of the cache data dirs # for the Cache data, or the Session saves, un-comment the desired settings # here: #beaker.cache.data_dir = %(here)s/data/cache #beaker.session.data_dir = %(here)s/data/sessions # Specify the database for SQLAlchemy to use via # turbogears.database # %(here) may include a ':' character on Windows environments; this can # invalidate the URI when specifying a SQLite db via path name sqlalchemy.url = sqlite:///%(here)s/somedb.db sqlalchemy.echo = False # WARNING: *THE LINE BELOW MUST BE UNCOMMENTED ON A PRODUCTION ENVIRONMENT* # Debug mode will enable the interactive debugging tool, allowing ANYONE to # execute malicious code after an exception is raised. #set debug = false # Logging configuration # Add additional loggers, handlers, formatters here # Uses python's logging config file format # http://docs.python.org/lib/logging-config-fileformat.html [loggers] keys = root, myapp, sqlalchemy, auth [handlers] keys = console [formatters] keys = generic # If you create additional loggers, add them as a key to [loggers] [logger_root] level = INFO handlers = console [logger_myapp] level = INFO handlers = qualname = myapp [logger_sqlalchemy] level = WARN handlers = qualname = sqlalchemy.engine # "level = INFO" logs SQL queries. # "level = DEBUG" logs SQL queries and results. # "level = WARN" logs neither. (Recommended for production systems.) # A logger for authentication, identification and authorization -- this is # repoze.who and repoze.what: [logger_auth] level = WARN handlers = qualname = auth # If you create additional handlers, add them as a key to [handlers] [handler_console] class = StreamHandler args = (sys.stderr,) level = NOTSET formatter = generic # If you create additional formatters, add them as a key to [formatters] [formatter_generic] format = %(asctime)s,%(msecs)03d %(levelname)-5.5s [%(name)s] % (message)s datefmt = %H:%M:%S On Aug 17, 9:14 pm, Michael Pedersen <[email protected]> wrote: > On Tue, Aug 17, 2010 at 6:55 PM, James Durham <[email protected]>wrote: > > > Well the error is that when I login on I get a 500 error, > > but I successfully log in as the user. > > (remember I am trying to deploy an unmodified > > quickstarted app.) > > Unfortunately, this is not the error you are getting. This is the error that > you are being shown in your browser. The error you are getting will be > displayed, in full, in your Apache error log. Since you have not provided > this error message, everything here will be conjecture. > > Based on this statement: > > > If run under paster serve, the behavior is right. > > I expect one of two things. Either your file system permissions are borked, > or you are running with the default development.ini as your ini file. That > default ini file has "debug = true" in it, which is not supported in > production mode, and will produce those sorts of errors in your display. > Considering this statement: > > > config the app with a production.ini and run paster setup-app > > I rather strongly suspect that you are using the default database, which is > a sqlite database named "devdata.db". This can (and does) work, but only if > your permissions are set correctly on the file. Make sure that the Apache > user has the capacity to read/write that file. I do not suspect that you > have "debug = true" in your ini file based on what you've said, but that > could be worth checking out. > > Now, if neither of those turns out to be the issue at hand, please tell us > the exact error message (from your Apache's error log) so that we can help > you diagnose the problem. > > Oh, one last detail: I have deployed TG2 using Apache and mod_wsgi on > FreeBSD 8, Ubuntu 10.04, Ubuntu 8.04, and some version of CentOS > (5.something, though I don't remember which version, since it's been a > while). As I've said in my IRC: the only issues I've had with this were the > usual "deploy to production" type issues of file permissions and package > versions that were incompatible with the local Python installation. It > works, and it's quite unfair to say that it doesn't before you've actually > told us what the specific issue you're experiencing is. And no, you have not > done that, since you have not shown us the problem. Log snippets and > backtraces show the problem, saying that the browser shows a 500 error tells > us nothing. > > -- > Michael J. Pedersen > My IM IDs: Jabber/[email protected], ICQ/103345809, AIM/pedermj022171 > Yahoo/pedermj2002, MSN/[email protected] -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
