I have a prototype application (RESTful web service database front-end) that is written using Dancer. As a prototype this runs fine under Apache with mod_proxy, and Dancer's routes work really nice.
My next step is to see if I can get this to scale a bit as some of the queries can be very slow and I don't want the slow queries blocking other requests.
I'd like to use rpms to manage the needed perl modules. For Dancer, this is no problem as CentOS-6 plus EPEL provide sufficient rpms to allow me to build/install Dancer and Dancer::Plugin::Database rpms.
Trying to build Plack rpms isn't working nearly as well however due to a varietly of reasons, one of which is that some of the system modules are too low a version number (and no, overwriting the system rpms with higher version local builds is not considered an option).
EPEL does provide rpms for CGI::Emulate::PSGI and HTTP::Server::Simple::PSGI but I'm not seeing how to wrangle either one of them into a desired solution.
So, my question is: Is there a clean/maintainable way to get Dancer running on CentOS-6 with pre-forking? Barring that, how does one get Apache to play nicely with a local perl install (where I can use tools like cpanm to install things)?
I highly recommend you the use of perlbrew, and forget the system perl.
If you want to restrict yourself to the packages shipped with CentOS, then you can run your Dancer app under mod_perl. There is a Plack adapter for mod_perl, so it is rather straightforward.
For example
<Location /myapp>
SetHandler perl-script
PerlHandler Plack::Handler::Apache2
PerlSetVar psgi_app /var/www/html/myapp.example.com/app.psgi
</Location>
Related
I have a perl script to install a web-application which needs to turn on mysql and apache if they are not already on and have those services start at boot if they are not already configured to do so. Later on, I'd like to check that the service is running before attempting to interact with it.
Right now my script branches on the os: are you Fedora? are you a Red Hat relative which is not Fedora? Are you Debian?...etc. That's so I know whether to use systemctl, service, or chkconfig.
Is there a better way to handle this? I was hoping for a module on cpan similar in cross-platform drudgery handling spirit as the best of perl's standard modules, but I haven't come across one. So right now adding support for a new OS means tracking down how it handles such services and watching for changes in this as new versions of currently supported os's come out.
Any suggestions for better ways to handle this or recommended approaches?
I install Bugzilla on my fedora server. I want to use Rest Api, but can't find how to activate it. Can someone help me?
This issue can be fixed by installing some Perl modules that were listed as optional. What worked for me was enabling mod_rewrite and also installing optional modules pertaining to the Bugzilla API. Make sure that all of the modules you have installed are up to date. You will also want to make sure you enable mod_rewrite so that you can contact /rest/ in your URL instead of /rest.cgi/
Example of enabling mod_rewrite for Windows:
https://tomelliott.com/php/mod_rewrite-windows-apache-url-rewriting
List of modules (required and optional):
https://www.bugzilla.org/releases/5.0/release-notes.html
Take a close look at the table for optional modules. Under the "Enables Feature" function, you will see these two perl modules are required for the API to function.
JSON::RPC (Any) JSON-RPC Interface, REST Interface
Test::Taint 1.06 JSON-RPC Interface, XML-RPC Interface, REST Interface
Note that you may need to look at different pages if you're on a different OS, or want to upgrade a different version.
The REST API is not bundled with the official Bugzilla release. You can get installation instructions here.
Is it a good or a bad idea to package and deploy web applications in rpm format. Did anyone experiment with this. ?
Thank you
It is a good idea, especially if your application relies on specific packages/libraries. It is also relatively easy to do, since httpd config usually just scans /etc/http.d on RPM-based distributions.
It is also much easier for people to try out your application versus having to go through a usually multi-step install HOWTO's.
You can look at RedHat's webalizer RPM for a sample on how to package web apps as RPM's.
Using Apache 2.2 and mod_perl on Ubuntu 8.04 I have several applications on a server. Using Apache in pre-forking mode. Usually things are working well but once in a while I see one of Apache processes using 100% of the CPU.
There are several web sites on the server with their own VirtualHosts and there are
is and SVN server running via Apache.
How could I track down which application and which calls in that application generate the high load?
Devel::NYTProf is pretty much the premier profiler for Perl right now, with Devel::NYTProf::Apache for easily profiling mod_perl applications.
See Tim Bunce: NYTProf v2 – A major advance in perl profilers for a pretty overview with pictures.
Unfortunately, Devel::NYTProf isn't pre-packaged in Ubuntu Hardy. (It is pre-packaged in Jaunty, Karmic, Lucid, and later.) You can either use some apt trickery to install packages from those distributions, install from CPAN, or just upgrade ;-)
If you have a large subversion repository and path-based authorization enabled in your apache configuration you're going to see some long-running, high CPU apache tasks. You'll probably also have complaints from subversion users about slow commits and updates, along with 503 errors and subversion complaining about truncated SSL responses. If this is the case, I'd make subversion my prime suspect.
Use a custom log format or a write a PerlLogHandler that records the request information along with the PID and resource use information. See, for instance, Randal's Web Techniques Column 48.
I want to host a mod_perl application on a shared RHEL server where I do not have access to a root account. mod_perl is available on the server as are all Perl modules required (my app runs fine with CGI).
Here are two problems I anticipate: Apache restarts would be required whenever I update my code the first time and subsequently on periodic updates. Second, I would have to use some <Perl> directives in .htaccess. I would be happy to hear experiences, gotchas, hints from others who might have done this successfully. Thank you!
This might not be useful in your case, but you can always run an
Apache instance in your home directory, and have the frontend proxy
incoming requests to that instance. That way, you have full control
over the configuration, Apache modules, Perl modules, and Perl itself.
It also uses system resources better (slow clients don't tie up the
heavy perl app, only the lean frontend instance), and is actually the generally
recommended way of deploying mod_perl applications.
Another option, and one that will involve less screwing around, would
be to get a $20/month VPS and use that. Then you can do whatever you
want, as you'll have full root access.
You can't do it without the ability to restart Apache httpd.
Perhaps the admin will give you sudo powers so you can do that at least.
Try Perl under FCGI instead.
You aren't gonna be able to use mod_perl without root on a shared hosting account. The "run my own instance" sounds okay, but you will need a way to start up apache if the server reboots.
FCGI is your best bet. That or get something where you can get root access to your own apache process. The added benefit of such an account would be you could install CPAN modules without going through the extra hassle of setting up a non-root library and messing with $PERL5LIB.