Any luck with mod_libpq under Apache 2.2 and/or win32? - apache

Has anyone had luck compiling mod_libpq for Apache 2? I know there were some fairly major changes so the source might have to be updated, but has it been done already by someone?
Also, has it been compiled for win32 (either version of Apache, or another web server altogether?)

I've written an updated version for Apache2.2 which can be downloaded from
http://asmith.id.au/source/mod_libpq2.c
However, it is my first attempt at writing a module for Apache2 and it is not debugged yet.
Previously I had no use for it as I was still using Apache1.3 but since I am now faced with retiring that old server I guess I'll have to finish off the new version.

Related

Drupal custom module failing to install

I have created a module on a development server (xampp) all is fine and working. However when I have move the module to my production server it fails to install properly, WSOD. From db I can see that my fields are not being created.
Drupal version 7.27 on both, both clean installs with the same dependencies installed.
Nothing in apache error log.
Grateful for any tips.
Mathew
ok just incase this helps someone else further down the line - this was an issue with different versions on PHP on the two servers one had 5.3 the other 5.5. One supports short form arrays [] and one does not which was my problem.
Would i have been able to resolve this from PHP logs?

Jruby 1.7.x compatibility with Warbler gemjar

I have an application using JRuby 1.6.7, Ruby 1.9.2, Rails 3.1.3 and Warbler 1.4.0.beta2
For a while now, I have been trying to update the application to use JRuby 1.7.x. Every time I tried (with versions 1.7.3, 1.7.4, and most recently 1.7.6) I would get the following error:
org.jruby.rack.RackInitializationException: No such file or directory - /home/production/var/tmp/Jetty_0_0_.war/webapp/WEB-INF/lib/gems.jar!/gems/activesupport-3.1.3/lib/active_support/locale/en.yml
After some help from this question here: Warble not including active support locale files, pin pointed that that issue was with the warbler configuration in my application. We had enabled the following configuration:
config.features = %w(gemjar executable compiled)
Specifically, the gemjar feature was the one causing the issue. With that feature disabled, everything works fine (the WAR deploys perfectly)
I am wondering, if anyone else has run into this, or if anyone knows what the issue might be?
And then more specifically, what are the disadvantages to disabling the gemjar feature of Warbler? From what I can tell, there shouldn't theoretically be anything devastating by disabling it... but I may be overlooking something.
(I do also wonder if the full warbler 1.4.0 release might fix this... but I can't find anything about when a release might be coming out)
there are none - actually running a .war with gemjar might have issues on some servers (esp. if they do not expand the deployed .war, since then it's quite hard to reference files/resources packaged in a .war while still inside a .jar). on the other hand it should roll fine if things are expanded (even with gemjar) ...
you should definitely report this with Warbler's repository (if not reported already).
it should not be hard to fix - likely a one liner, I know a PR would be most welcome :)
NOTE: on the other hand if it worked in a previous JRuby and updating 1.7.x is the issue, than it might be a "regression" on JRuby's side and they might actually fix this if they knew about it ...

Outdated version of Zend Engine API

I am hosting a website, using the Symfony framework, on a MAMP server on my Mac, and I'm trying to generate bundles automatically with the help of the terminal.
If it is relevant in any way, here is what I try to type into the terminal:
php -c /Applications/MAMP/bin/php/php5.4.10/conf/php.ini php
app/console generate:bundle
And here is the error I get:
XCache requires Zend Engine API version 220100525. The Zend Engine API
version 220090626 which is installed, is outdated.
Could not open input file: php
Do any of you have an idea of how I could update the Zend Engine API or otherwise fix my problem? That would be of HUGE help!
Edit:
Thanks to the help of whistlergreg I've gotten rid of one of the problems it seems, but I still get the following response:
Could not open input file: php
Edit:
I was told by someone that the second php in my command shouldn't be there. Instead I should write:
php -c /Applications/MAMP/bin/php/php5.4.10/conf/php.ini app/console
generate:bundle
It seems like the second error was caused by a noobish typo by me, and now everything is working.
Note: With Xcache 3.0, xcache.so is no longer a Zend Extension but a PHP extension
remove zend_extension = */xcache.so
load it using extension = xcache.so
This might be why the error is being thrown:
The main cause for the error is because of outdated build of XCache
(not related to its actual version though), that mostly happens when
user upgrades PHP version. When compiling and building XCache, it’s
been associated with the version of Zend Engine API that exists on the
system at the time.
When PHP is updated or upgraded, the Zend Engine API is updated too, causing XCache module to fail as the version no longer matched.
The solution for the Zend Engine API version is newer error is pretty
simple. Just download, compile and install XCache again will fix and
resolve the issue permanently (until new PHP major version update). 1
Switch MAMP to use APC from the MAMP preferences menu, that worked for me! Make sure you restart apache after making the change.

Trying to transfer older version of mediawiki to new server

So, in college I had a Debian server which used to host a wiki, with mediawiki version 1.9. This server stopped working, and all I have now is its HD. I want to transfer this wiki to a new server, which also runs Debian, but I can't do that with Debian's current stable version of mediawiki, 1.15, because it is not possible to transfer a wiki to another version of mediawii.
So, my idea is to install mediawiki 1.9 on the new server, and then move the wiki. But I am having problems with installing it.
When I go to http://my_hostname/config/index.php, to configure the new wiki, so that I can transfer the other one, I get the following message, and nothing happens:
Checking environment...
Please include all of the lines below when reporting installation problems.
PHP 5.3.3-7+squeeze8 installed"
I really don't have a clue on what is wrong. ANY help would be greatly appreciated!
Like you commented yourself, it would certainly be worth a try to using your existing configuration. The configuration is typically some site preferences and database configuration, so make sure dat your database is setup in the same way as before.
Regarding your configuration problems, maybe php filters away the errors. You can check this by searching for error_reporting in your php.ini.
Just follow the instructions at http://www.mediawiki.org/wiki/Manual:Upgrading. Probably no point in trying to install at MediaWiki 1.9.
You may want to do a clean install of MediaWiki 1.18.1 first just to make sure your system is ready, all dependencies met, etc.

Is there some place to download an AIX mod_jk binary?

I needed to front tomcat with apache on AIX, but there is nothing in http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/aix and googling around was unsuccessful. I eventually built it from source (painful as there is bureaucracy around getting the compilers installed at this large corporate).
But shouldn't this binary download exist somewhere? Why do they just have an empty directory?
My guess is that they don't have an AIX or FreeBSD (also not there) machine around to do it. Perhaps you could volunteer your build?
AIX is not the only neglected platform.
General interrest and support for the mod_jk project seems to have diminished since the introduction of mod_proxy_ajp into the main source of apache-2.2
This modules performes basically the same functionality as mod_jk and does not need an extra install.
The version of apache-2.2 I got from http://gnome.bullfreeware.com/aixtoolbox/RPMS/ppc/apache/ also contains this module.
Is there a reason to get the binary and not compile it? You can get all the source from apache's svn.