Hi, All this talk of configuration and deployment management reminded me of the problems I encountered while creating Webware RPMs. I have pretty good Mandrake RPMs for Webware and its docs but the mod_webkit RPM for Apache2 I created leaves something to be desired. Well packaged RPMs for Apache modules will not only install the DSO files in the right place but should modify httpd.conf and restart Apache to activate the configuration changes. I have a few problems with doing that for mod_webkit.
I had to use the Mandrake RPM macros for doing make install as the Makefile included with Webware was never intended to be used to by a non root user. When I used the make install RPM macro to work around this, rpmbuild then complained that marshal.so was created but not packaged. When I added it to the files list that RPM is supposed to install, the RPM built properly but now I see mod_webkit.so and marshal.so in $buildroot/usr/lib/apache2-extramodules. If I just do make and make install manually, I do not see marshal.so being installed anywhere. What is this marshal.so? Can I just ignore it in my RPM and not install it at all? There are RPM macros for modifying httpd.conf and restarting Apache to activate the changes. However, if one is using MakeAppWorkDir to create working directories and running multiple instances of Webkit listening on different ports, having the RPM modify the conf file would not make any sense as it could only do it for one instance. For each instance of Webkit, there would have to be a corresponding entry in httpd.conf. This is where this MakeAppWorkDir model of deploying applications makes things more difficult, particularly in a shared hosting environment, as it is does not seem like it would be easy to automate using RPM. Perhaps MakeAppWorkDir should be modified to make the necessary changes to httpd.conf and restart Apache. If we install from RPM, normally that would install the init script. If we are running multiple instances of WebKit, how would that work? We would have to have one init script per instance. This ties in with MakeAppWorkDir. Perhaps the best approach would be to move all the functionality of MakeAppWorkDir to an RPM per Webware application. So, we would have RPMs like python-webware-common, python-webware-doc, mod_webkit2, and myApp1, myApp2, etc. The myAppX RPMs would have to be created per web application. Once a skeleton spec file is created, it is not very difficult to flesh it out and build the RPM. This would make deploying one's web apps as easy as: 1. modify the skeleton spec file for the web app, 2. build the RPM for the web app using the spec file from Step 1, 3. run genhdlist to regenerate the RPM list for the urpmi repository, 4. add the urpmi repository created in step 3 to your urpmi media source, if you had not done so previously, 5. urpmi myApp1 myApp2... I have come to appreciate the flexibility of RPM after having to migrate Webware applications from one server to another without using RPM. A Webware application usually relies on other things, like a SQL back end, an ORB such as SQLObject, the egenix-mx utilities, db drivers like psycopg, etc. so it is not a trivial undertaking to install and configure all this stuff. Creating RPMs has given me the ability to go from bare metal to a working web application in under an hour and have it work the first time, every time. I have not looked at WSGIKit to see how easy it would be to package as an RPM. I suggest to those who are developing WSGIKit, please pay attention to how WSGIKit is packaged as a tarball. If there is clean separation between the server components, docs, and Apache modules, it makes it much easier to package as an RPM. If we want the community to grow, having Webware/WSGIKit included with distros, or at the various least, as a contrib would help. Comments? Suggestions? Answers to my questions above? -- Regards, Clifford Ilkay Dinamis Corporation 3266 Yonge Street, Suite 1419 Toronto, ON Canada M4N 3P6 +1 416-410-3326 ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Webware-discuss mailing list Webware-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
