(oops, sent too soon)... Instead of: if __name__ == "__main__":
I have: def main(): This way, the very thin executable script loads my program as a module and executes "main". (This is pretty typical arrangement for a python program with multiple modules.) Finally, I run it like this: nohup /opt/myapp/bin/mycode >> /dev/null 2> /var/log/mycode.log & Make sense? If you wanna dive in to the full blown craziness of our app as a reference, https://github.com/cloudsidekick/cato/blob/master/lib/catoadminui/catoadminui.py On Thu, Dec 12, 2013 at 12:43 PM, Shannon Cruey < [email protected]> wrote: > 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.
