Re: distributing software built on mod_perl
On Fri, Sep 25, 2009 at 7:32 AM, Mike Barborak barbo...@basikgroup.com wrote: I think I see what you're saying. It seems like a very expensive problem to solve. It must be a barrier to people choosing mod_perl to develop their apps because it might be the case that their distribution and installation process is more complex to develop and support than their actual applications. That's what it's looking like in my situation and so I'm going to reevaluate using mod_perl. It's not limited to mod_perl. It's limited to any shrink wrapped software. It's less of an issue with software that can be self contained versus software that is shared on the system. But it seems like there's a lot of generally repurposable results in your efforts that could make distributing mod_perl applications more straightforward. It seems like at the core of what you do is a massive distributable that contains: * mod_perl binaries * perl binaries * necessary perl module binaries * project-specific binaries I would split up the distributable by platform since that is the granularity you care about. I usually rely on package that are already provided by various distributions. My target platforms are usually RedHat, Debian, and FreeBSD which all have stable mod_perl+apache packages already, as well as a significant number of perl packages available. I then backfill any packages which are not available for that distro so really all I have to maintain is the difference between the packages I use, and what the distributions already provide. This massive distributable contains these binaries built for all the supported platforms and all the supported versions of Apache. So if we say that there are on the order of 10 platforms that need to be supported to cover 95% of all installations and there are 5 versions of Apache to support (just guessing with both numbers), then it would be a matter of building: * 50 versions of the mod_perl binaries * 10 versions of the perl binaries (multiplatform installations supported by perl already) * 10 versions of the necessary perl module binaries (multiplatform installations supported by perl already) * 10 versions of the project-specific binaries 10 platforms seems a bit excessive, but then again it depends what your counting as a platform. ie. RedHat/Debian, RHEL 4.2/4.3, or RHEL 4/5. If your platform is a distribution then your dependency chain is different for each platform . If your platform is minor revision of a particular distribution, then it may not matter so much, it's probably the same dependency chain. If they are different major versions, you can go either way depending on if it's common for both major versions don't have too many differences in the dependency chain. In all cases though you want to leverage work already done by the various distributions as well as third party package repositories to reduce your own overhead. This would take a lot of effort to setup but doesn't seem unreasonable to maintain. And with this binary repository in hand then it seems the distribution problem really does become fairly straightforward; it's just a matter of figuring out the target platform and apache version and then producing an appropriate apache configuration snippet. That seems a lot easier than trying to walk a client through the process of getting the development version of apache, getting the necessary build tools, building mod_perl, building perl modules, etc. It also seems like it would make less of an impact on a client's existent system that replacing their web server. It's a tradeoff of up front work to figure out which platforms your going to support, and what that means in terms of your dependency chain, versus an unknown dependency chain and trying to mitigate all the variance you may encounter in your support calls. That isn't to say you can't take a middle ground as well so long as the risks are understood. It may in fact be cost prohibitive to do the right thing and track entire dep chains especially if your trying to support a large number of platforms. So the question becomes what is good enough. How much can you maximize number of supported platforms while minimizing support risk? So is it a pipe dream to think that such a repository of non-project-specific binaries could be made publicly available to mod_perl application developers? Some of the problems I see are: * Have I captured all the variants or would you also have to build version for all the various versions of libc, mysql, etc.? * For customized perl modules and your own application, what would the resource be to build it on all the supported platforms? Perhaps this is where someone could monetize this scheme. There is is the idea of following your dependency chain until it is good enough versus following it all the way to libc versions and kernel versions. My rule of thumb is to only follow language/library which is what I would consider prime
Re: double mod_perl initialization
On Sep 25, 2009, at 10:36 AM, Jonathan Swartz wrote: As I understand it, the sole purpose of this double initialization is to make sure that graceful restarts will work. However, since I was a young mod_perl lad I've been taught never to rely on graceful restarts, and always to stop/start. This happens right along: * a bug is found in a piece of software, * the bug gets publicized and responded to and remembered by many people, * the people maintaining the software fix the bug, * but for months and years into the future, people remember the bug and keep working around it. Apache's graceful restart worked fine years ago, but started losing badly at some point. I probably wasn't the only person to write a script called 'graceful' to use instead of 'apachectl graceful'. My log rotation script still uses a variant of 'graceful', but that's mostly because it determines when it's OK to process the log. But at some point, several iterative fixes by the Apache crew had succeeded such that 'apachectl graceful' worked better than my 'graceful' script in some way. It was sufficiently long ago that I've forgotten in what way, but the memory is clear enough that I think Messrs. Swartz and Clint are beating a dead bug. I use 'apachectl graceful' a lot, and can't remember a problem for a long time. Of course problems still exist with older versions of apache2. If they work, graceful restarts are a good thing in that they're as nice as possible to users on a production web site. Double initialization does not prevent problems with restart (graceful or otherwise) for most configuration or perl problems. Isn't that because by the time the root httpd starts the first (re) initialization it has already notified the children (that use the old configuration and code) to go away? So if restart is the reason for double initialization, by all means let's encourage the Apache folks to reconsider the idea, and work around it until they do. cmac P.S. sudo's were omitted for brevity.
Re: problem with CSS in a dynamic document
I would like to thank everyone for the very useful information. I have gotten everything to work well. Also, the diverse views have given me more options to try. I am new to this 'web thing', having done system level programming for over 30 years. I am trying to learn the various strategies and the strengths/weaknesses of the various technologies. I am currently implementing a small-ish project for myself and will explore using PHP and then PHP/Drupal on this project. I would really appreciate it if people would comment on their views of these differing technologies, what project types they are appropriate for and their experiences with them or tell me where I can find these discussions on the web. I can see some differences but until you have worked with them on a large project it is really difficult to know the pitfalls. Please feel free to email me directly rather than the full email list. Again, thank you for your help! Chuck On Sat, 2009-09-26 at 00:15 +0800, 叶孤城 wrote: 2009/9/26 Bruce Johnson john...@pharmacy.arizona.edu: or just print the html. When executed as a cgi script, the outgoing connection from Apache is the script's stdout. Variables substitute just fine. print EOF; Content-type: text/html\n\n html link rel=stylesheet href=./dynamic.css type=text/css titleHowdy $username!/title ... /html EOF Works for us. This way I can do large swaths of straight html code without any issue, and no potential complications from added modules. printing html directly in CGI scripts is maybe convenient for a small application. but, its maintainability is worse when the project is increasing. I may think also using a template is better, that make perl code separated from front-end codes (html/js/css etc), and make both perl programmer and designer happy. I personally prefer Template::Toolkit for CGI and Mason for mod_perl. //yegucheng
Re: double mod_perl initialization
On Sep 26, 2009, at 4:17 AM, Clinton Gormley wrote: I'm using apache 2.2.9, mod_ssl 2.2.9 and mod_perl 2.04, and I still have problems with graceful-restart. You are 4 releases behind. Download 2.2.13 and I bet graceful will work for you. (Bet's off if you have something systemically difficult w/r/t ssl.) Throw in a mod_perl 2.0.5 from SVN: I've never seen such performance as the system I built with 'optimize -Os' last night. In my setup, I know that it can do this, and so I'd rather avoid that double init. I would too. I was defending graceful restart, not double init. cmac
Re: double mod_perl initialization
But at some point, several iterative fixes by the Apache crew had succeeded such that 'apachectl graceful' worked better than my 'graceful' script in some way. It was sufficiently long ago that I've forgotten in what way, but the memory is clear enough that I think Messrs. Swartz and Clint are beating a dead bug. I'm using apache 2.2.9, mod_ssl 2.2.9 and mod_perl 2.04, and I still have problems with graceful-restart. It works under certain conditions, but (i think) combined with mod_ssl, my httpd children hang around indefinitely, unless I set GracefulShutdownTimeout. For this reason I use: apachectl graceful-stop; apachectl start Double initialization does not prevent problems with restart (graceful or otherwise) for most configuration or perl problems. Isn't that because by the time the root httpd starts the first (re) initialization it has already notified the children (that use the old configuration and code) to go away? So if restart is the reason for double initialization, by all means let's encourage the Apache folks to reconsider the idea, and work around it until they do. Because apache (normally) starts up as root, then drops privileges, it tries to confirm that it can restart as not-root. In my setup, I know that it can do this, and so I'd rather avoid that double init. Also, I'd rather avoid setting up my whole application just to shut down apache. So, YMMV, but it works well for me. clint
