× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I'm curious about how you get to the blog? I'm wondering if your issue is
related to something I experienced with a different product while I was
testing.

I'd go to http://www.mydomain.com:8000/ and I couldn't log on because the
login form's action was pointing to http://www.mydomain.com/ which behaved
differently.

On another occasion which I didn't get around to fixing, just circumventing,
if I'd go to http://www.mydomain.com/ I could log on but if I'd go to
http://mydomain.com/ the session wouldn't start correctly so I couldn't log
on.

Alfred

On Tue, Mar 17, 2009 at 16:13, Pete Helgren <Pete@xxxxxxxxxx> wrote:

Chasing the tail a bit on this one....

I took Alfred's advice and bypassed the proxy and ended up with the same
problem! The blog displayed just fine but the I still couldn't log in.
That took me on a slightly different search route and I ended up
attempting to log in with IE, which worked. So there is some 'quirk'
with Firefox that I will have to sort out, but the application is
working as designed as far as I can tell. I just have to use IE in
order to update the blog (at the moment).

Two things to pay attention to:

I have a web page and the blog is a subfolder on the web page. I needed
to use the following as part of the httpd.conf setting in the i5/OS web
admin.

ProxyPass / http://127.0.0.1:8000/mywebfolder/
ProxyPassReverse / http://127.0.0.1:8000/mywebfolder/

And I needed to make sure that 1 of the following two things were also
set. Either add the following directive in httpd.conf

ProxyPreserveHost On

Or, use the following hack in your wp-config.php file:

if ( isset( $_SERVER['HTTP_X_FORWARDED_HOST'] ) )
$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];

Both approaches seem to work.

I am mystified by the Firefox problem and, while jumping back and forth
between the i5/OS web admin and clearing cookies from Firefox, I have
now broken the login for the Integrated Solutions Console that gives me
access to the i5/OS Web Administration application. Sigh....fix one
thing, break another.

In any case, if you install WordPress and use the directives for
proxypass and ProxyPreserveHost, you should be able to get it to go.

I also had changed the siteurl and home settings in the wp_options table
in the WordPress database. I can't remember the original values but you
may want to inspect them if you are still having trouble accessing your
WP site.

Pete


Pete Helgren wrote:
Thanks Alfred, for that thorough reply.

So it looks like when I leave the i5/OS Apache instance out of the mix,
I do all my configuring in /usr/local/Zend/apache2/conf/httpd.conf.
I'll add a couple of virtual host entries to manage what I *was* doing
in the i5/OS version of Apache and I should be good to go. I can leave
the port at 8000 since my firewall is ISA and it can map a port 80
request back to 8000.

I'll have to look into that. The proxypass entries now make a little
more sense to me. It is passing it off to PASE instance. I'll see if I
have any better luck dealing directly with that instance.

Pete


Alfredo Delgado wrote:

An early strength of PHP over other web scripting platforms was that it
runs
as an Apache module instead of a separate CGI process that is spawned
when a
PHP request comes in. However, it can run as a separate CGI engine and I
did
that on the i for 2-3 years before switching to Zend's official release.
Instead of running like a CGI engine, Zend Core takes the typical PHP
approach of running as a module of Apache. That Apache server is the one
that's in PASE. In essence, Zend Core for i5 is AAMP (AIX, Apache,
MySQL,
PHP).

Normally in a CGI process, a request comes in for *.php and there are
Apache
directives telling the web server to pass that request off to the PHP
binary. When the engine is finished with the request, it outputs its
XHTML
etc. back to Apache which then serves it to the browser.

By running PHP as a module, the extra steps of sending the request off
to an
outside binary are removed and every Apache job basically speaks PHP
instead
of just simply serving traffic.

With Zend Core, the proxy directives are taking the *.php requests
received
by an i5/OS Apache instance and sending them to Apache in PASE. The i5
Apache instance is just another client to Apache in PASE. Once the PHP
request is handled by PASE Apache, whatever outputs is taken by the i5
Apache and served to the browser.

As long as there isn't a firewall between you and your system, you can
directly talk to the Apache server in PASE. It's a full Apache install
so it
has its own logs and a conf file which you can edit. It's located at
/usr/local/Zend/apache2/conf/htttpd.conf so if you don't have any other
server listening on port 80, you can have it listen on port 80 instead
of
port 8000. I did mention that I ran into a problem with PASE Apache in
that
it can't listen to more than one port. If I want to make a connection on
port 443, I either have to take every connection securely or I still
have to
bounce the connection off an instance of i5/OS listening on port 443
which
then proxy's locally to port 80. Zend support has also provided me with
a
solution where I would have to run two Apache servers in PASE -- one
listening on 80 and one listening on 443 with mod_ssl.

Now why wouldn't everybody skip the proxy step? I asked that of the list
and
I believe Scott gave the best answer. Some people have been developing
web
applications on the i long enough that they're using hooks only
available in
an i5/OS instance of Apache. My company isn't tied to any i5/OS specific
feature of Apache so we had the freedom to do this and Zend support has
been, y'know, supportive of that choice. The've actually taken the time
to
help with issues like the one I mentioned above instead of giving me the
response I expected. e.g. 'piss off, that's not an official install.'

Alfred

On Tue, Mar 17, 2009 at 12:11, Pete Helgren <Pete@xxxxxxxxxx> wrote:



Alfred,

So, how do you configure this? I have always been a little uncertain
exactly *where* the "true" PHP server resides. Is it at 8000 or at 89?

An example of how you accomplished what you described below would be
helpful.

Pete


Alfredo Delgado wrote:


Todd,

If that's the choice then why not just avoid the proxy step and serve
directly off the Apache instance in PASE? That's what I'm presently


doing.


The only problem I've run into so far is that if I want to make both


regular


HTTP connections and SSL connection I still have to proxy through
i5/OS
Apache or run two instances of Apache in PASE.

Regards,
Alfred

On Mon, Mar 16, 2009 at 17:10, <TAllen@xxxxxxxxxxxx> wrote:




As far as I can see, it is definitely the ProxyPass causing the pain.
I
don't see any way around it. It looks like we'll be forced to chuck
it


and


move to a Windows server. I'd really rather not do that but don't
have


a


choice at this point. Maybe I can come back to it later if someone
at


Zend


can provide a way around it.

Thanks,
Todd





Pete Helgren
<Pete@xxxxxxxxxx>
Sent by:


To


web400-bounces@mi Web Enabling the AS400 /
iSeries
drange.com <web400@xxxxxxxxxxxx>



cc


2009-03-16 16:49


Subject


Re: [WEB400] WordPress with
Zend
PHP
Please respond to
Web Enabling the
AS400 / iSeries
<web400@midrange.
com>






Jim,

When I get it going I will. Right now the proxy pass directive (I
think) is causing WordPress quite a bit of pain.

I am going to post to the WP support site but I am still not sure if
it
is WP issue or one with the Apache configuration in Zend.

Should I post in the Zend i5/OS forum as well?

Pete

Jim Dillard wrote:



Pete,

Thank you for this!

Please post similar information for Wordpress. I would like to
create


a


link from the Zend forums to your post here regarding Wordpress.

IBM's Michael Sandberg has a post with the install instructions to
many
open source applications (SugarCRM, MediaWiki, phpBB, etc.) and your
information will be another link.

Thanking you in advance!

Jim Dillard
IBM Alliance Manager
Zend

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:
web400-bounces@xxxxxxxxxxxx]
On Behalf Of Pete Helgren
Sent: Monday, March 16, 2009 10:51 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] WordPress with Zend PHP

Todd,

I am not using Wordpress (yet) but in Serendipty (another blog php
app)
I used the default 80 port. The proxy pass directive handles the
"translation" to/from the default port you specify in the web
configuration file in Web Admin.

My (relevant) configuration settings in Web Admin look like this:
# Configuration originally created by Create HTTP Server wizard on
Mon
Feb 05 16:09:18 MST 2007
.....
Listen 10.0.10.206:80 http
DocumentRoot /www/zendcore/htdocs
.....
DirectoryIndex index.html index.php
ProxyPass / http://127.0.0.1:8000/mywebroot/
ProxyPassReverse / http://127.0.0.1:8000/mywebroot/
<Directory />
Order Deny,allow
Deny From all
</Directory>

<Directory /www/zendcore/htdocs/mywebroot>
Order Allow,Deny
Allow From all
</Directory>

<Directory /www/zendcore/htdocs/mywebroot/myblogroot>
Order Allow,Deny
Allow From all
</Directory>

I do plan to install Wordpress because I have run into a couple
issues
with Serendipty and would like to use Wordpress.

Pete


TAllen@xxxxxxxxxxxx wrote:




Has anyone gotten WordPress to work with the Zend PHP product? I'm




having




no success, mainly due to the fact that there are basically 2
servers




- the




native Apache server and the Zend Apache server running in PASE.




WordPress




originally set the site URL (WordPress address) as 127.0.0.1:8000




(PASE




server). Changing that to the real IP address seemed to fix the




problems




but there is another address in the settings for the blog address,




which is




set to 127.0.0.1:8000. Changing the blog address to the real IP




address




caused the WordPress home page to become unreachable.

To change the theme I had to update the blog address to the real IP




address




and then change the address back to 127.0.0.1:8000 to get to the
WP




home




page.

Perhaps WordPress is too smart for its own good but it seems this




problem




could come up with other PHP applications.

Thanks,
Todd




This communication and any transmitted documents are intended to be
confidential. If there is a problem with this transmission, please


contact


the sender. If the reader of this message is not the intended
recipient,


or


the employee or agent responsible to deliver it to the intended


recipient,


you are hereby notified that any dissemination, distribution or
copying


of


this communication is strictly prohibited.

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.







--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.






--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.