As far as I know, CherryPy is a slightly lower level tool that was originally included in the web.py code. I've not really dug in to understand that, so I can't be sure.
I do basically the same thing you've done there to enable ssl. I use the Python logging module to write all the output to a rotating file. http://docs.python.org/2/library/logging.html That's quite a project in itself understanding that, but there's plenty of examples out there. Regarding daemonizing it, here's what I did. My directory structure is: root /lib /mycode /mycode.py /__init__.py /bin /mycode I have a "wrapper" executable file that looks like this: #!/usr/bin/env pythonimport sys import os base_path = os.path.dirname(os.path.dirname(os.path.dirname(os.path.abspath(sys.argv[0 ])))) lib_path = os.path.join(base_path, "lib") sys.path.insert(0, lib_path) from mycode import mycode if __name__ == "__main__": mycode.main() Then, my main python source file, "/lib/mycode/mycode.py", instead of the sample: if __name__ == "__main__": On Thu, Dec 12, 2013 at 12:19 PM, Steven Brown <[email protected]>wrote: > Wow, thanks for that detailed explanation! I had picked up a few of > these details, but you really tied it together for me. The only reason I'm > really worried about using an external server, is that I want to do things > the right way; I was worried that the built-in web.py server is only > designed for testing/rapid prototyping and shouldn't be actually > deployed/used in production. But if that's not the case, if it's "ok" to > use, I'm more than happy to do so! I just reviewed my index.py, and I have > a couple of references to a CherryPy webserver, imported from a wsgi > class. But, that's just to enable encryption: > > from web.wsgiserver import CherryPyWSGIServer > > CherryPyWSGIServer.ssl_certificate = root + releaseName + > "/security/certificate.pem" > CherryPyWSGIServer.ssl_private_key = root + releaseName + > "/security/keyfile.pem"import os > > Is CherryPy the builtin server, or is something else weird going on? Am I > actually using WSGI because of those lines, or am I just using one module? > It looks like I'm just setting a couple of variables, and then other > behind-the-scenes things turn on when they see that the correct files are > bing pointed at. The security stuff worked just fine when I tried it, but > the procedure I followed was a while ago so I forget a lot of the details. > > So if I'm going to just leave the server as it is, how do I go > about/should I worry about making it a proper daemon? And much more > importantly, how should I deal with logging, like redirecting stdout and > stderr? Is there a module or other package to do that, or is doing it from > the command line really the correct way? Like I mentioned in my original > email, I just want to be doing things the right, non-cludgy way. > > > On 12/12/2013 08:42 AM, Shannon Cruey wrote: > > Steven, I'll try a different approach in describing this, maybe it'll > help. I often find if I explain something to my wife, it suddenly makes a > lot more sense to me! Plus, with my morning coffee I try to do something > fun, so today it's my own twisted version of "web tech history". :-) > > HTTP (HyperText Transfer Protocol) was originally designed to deliver > static text content from a server to a browser. Basically, the original > web server was nothing more than a bit of code that read files off the > drive and delivered them over the TCP/IP protocol to a client capable of > rendering html markup to the user. Although it's evolved since then, at > their core tools like Apache and nginx are http servers, basically > fulfilling the same role. > > Since the original browsers didn't have Javascript, developers > immediately realized static content wasn't good enough. Rather than hack > up the web server with tons of new features and bloat, the designers > rightly decided to keep the server simple, and allow external extensions > via a standard interface. The common gateway interface (CGI) was born. > Using CGI, a web server could "hand off" a request to an external program > (written in almost any language). That external program will do it's > magic, and hand the result back to the http server, which will deliver the > content to the browser. Basically, it stuck a plugin in place of reading a > static file, allowing dynamic files. > > CGI, while a quick fix to the problem, eventually sort of died under the > weight of it's inherent problems. Each request had to fire off a process, > therefore performance was slow. Each of the leading http servers came up > with their own replacement for CGI. (Apache modules, NSAPI and ISAPI > plugins, etc.) The industry fractured into turf wars about the best way to > do server side code. > > Things have never really settled down, many alternate ways to do server > side code are available, from ASP.NET to PHP, each one communicating with > the server using an interface that was an evolution of CGI. > > Finally, WSGI is a semi-unique beast. Python initially lost some ground > as a web programming language, as the choice of servers and interfaces was > limited. Code could be hooked to a few web servers using CGI, FastCGI, or > an Apache module called mod_python, all arguably suboptimal in some regard. > Enter WSGI - a "middleware" between a python framework and any web server > willing to implement an interface. WSGI is the best way to build web > services using python, as it provides the richest interaction between > python code and an http server. > > (Web.py has implemented a wsgi interface, meaning you can technically > hook it to any server that supports wsgi. Apache and nginx are the > favorites.) > > There was an explosion of frameworks in the early 2000s to help > developers dynamically build static pages, loaded with widgets, tools and > "best practices". Confusion, showboating and religious wars abound to this > day. > > "Web 2.0" also came along in the early 2000's, and using ajax and > javascript, the web applications with the richest user experience now make > far less use of server side processing, offloading a lot of the logic to > the browser. The big frameworks have struggled to integrate client side > code into their models, as the browser is "outside their sandbox". > > We've come full circle - now that the leading browsers (yes, even > IE9/10) are pretty consistent, it's easy to distribute the work out to the > clients and build really powerful web applications. This has (to a degree) > reduced the load on the web server - where once you'd build complex server > side logic to create and serve a static page, now that's shift(ing/ed) to > serving *data* to the browsers and letting them build the visible content. > > Which is why web.py is my favorite - it doesn't presume to tell me the > best way to do anything - I get to decide. I can generate my pages in > python code, or I can deliver JSON to the browser and render it using > javascript, or I can build a REST API interface on a legacy application, > and I can do any of these with or without an external web server. > > My coffee is done, and so am I. If this helped anyone, cheers. If it > didn't, ignore it! > S > > Final thought - why do you feel you "need" to use an external web > server? We have four applications, all just use the built-in server, and > all serve tens of thousands of requests per day. There are certainly many > valid reasons to use an external server, just keep it simple if you can. :-) > > > > > > On Thu, Dec 12, 2013 at 6:41 AM, Joey Chang <[email protected]> wrote: > >> I think you should start from CGI. >> http://en.wikipedia.org/wiki/Common_Gateway_Interface . >> *Common Gateway Interface* (*CGI*) is a standard method used to generate >> *dynamic >> content on web pages and web applications >> <http://en.wikipedia.org/wiki/Web_applications>*. >> CGI provides an interface between the web server and programs that >> generate the web content. OK, the web server is like nginx or apache >> things, and the the programs which generate the web content like web >> frameworks. We call web application. >> >> So, we can draw a request/response line stream below: >> >> --------------------------- request -----||---------handle------||---- >> response ----------------------- >> Client -> web server -> cgi -> web application -> cgi -> web server -> >> client >> >> wsgi is a protocol like cgi but more advanced which implemented by >> python. >> uwsgi is like more advanced cgi, too, which can be implemented by lots of >> languages (i.e. python, lua ). >> >> And how these things work together? Only just set the right >> parameters in their conf files (containing log set), which you can google. >> >> Maybe, my description is not clear, wish would help you. >> >> >> 2013/12/12 Steven Brown <[email protected]> >> >>> Thanks. I looked over the web.py section of that link; there wasn't a >>> lot there. For one thing, nothing at all about nginx. Now I probably >>> should have mentioned that I'm very new to web programming, so a good >>> number of things that may be obvious to others won't be to me. So....what >>> *is* uwsgi? Is it the same as wsgi? In the example given, where do the >>> logs/stderr/stdout go? And does the example use nginx, somewhere under the >>> hood, or what? I guess my major confusion stems from the fact that I >>> thought web.py as a web framework, has everything you need. It has >>> certainly served webpages for me. I thought it was basically a replacement >>> for i.e. Apache? Or is the server separate from the framework? Is the >>> framework just in charge of generating pages, and the server actually >>> delivers them? nginx seems to be a server, in addition to other stuff I >>> don't know what it does, but then what does uwsgi/wsgi actually do? The >>> WSGI homepage says it's a full stack for building hosting services. I >>> don't know what that means :P >>> >>> On 12/10/2013 10:47 PM, Joey Chang wrote: >>> >>> webpy + uwsgi + nginx >>> http://projects.unbit.it/uwsgi/wiki/Example >>> >>> It's simple and convenient. >>> >>> >>> >>> >>> 2013/12/11 Steven Brown <[email protected]> >>> >>>> Hi everyone, it's been quiet for a while on the list! I am trying to >>>> do my servers the Right Way, but I'm not sure what I should/need to do. >>>> First, I want to properly daemonize my server. I have been doing >>>> something like >>>> >>>> nohup python myServer.py 1234 & >>>> >>>> but I'm not sure if that really covers everything. I feel like there's >>>> some "official" way to make a process a daemon, that does everything >>>> correctly, but I'm not sure what it could be! That way is also not so good >>>> with logging; I want to send all my stdout and stderr to a log file, or 2 >>>> log files, if that can happen. Doing it on the command line with > >>>> redirects hasn't really worked, and I feel like that's not what I should be >>>> doing anyway. And then there is the Deployment section on the website, but >>>> I'm not sure if I actually need any of that...I mean, I don't get why I >>>> need to use Apache, for example. web.py works out of the box, so what >>>> would I add yet another program to my stack for? But, I do want to do >>>> things right, so if I need to use Apache or whatever I will; but then, I >>>> don't know how to make a decision on which method to use.... >>>> >>>> Overall, the documentation is just a bit fragmented, and I'm not sure >>>> how to pull out what I need. Can anyone offer some insight? >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "web.py" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/webpy. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "web.py" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/webpy. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "web.py" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/webpy. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "web.py" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/webpy. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to the Google Groups > "web.py" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/webpy. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "web.py" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/webpy. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "web.py" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/webpy. For more options, visit https://groups.google.com/groups/opt_out.
