My current distributed(3server) installation of Cognos 8.4 is sitting in our Server Farm network. I have created an Apache server in our DMZ and setup ProxyPass from it to the Cognos Gateway in the server farm.
When I navigate to cognos.mycompany.com its redirecting to the internal network which times out for external users. Is there something I’m missing? My Apache conf file for the DMZ server is:
Let me know if you need any further information. TIA
Update: ProxyPass is definitely working correctly, this must be Cognos refreshing the page and feeding it the internal IP address. I’ve set the Gateway URI on the Reporting Server to the DNS but its still going to the IP. Is there somewhere else in the configuration settings that would cause this?
the post you referring to is for controller only. I have used this post a while ago to install and configure Cognos controller 8.5 on 2 servers WITHOUT proxy. The BI components on 1 server and the controller component on the other. In controller administration you see these 3 items.
CASUrl: http:///cognos8/controllerbin
Modify the WSSUrl: http:///cognos8/cgi-bin/cognos.cgi?t=controller
Modify the HelpUrl: http:///cognos8/controllerhelp
A reverse proxy server is a firewall-like implementation of the proxy server configuration. The proxy server is used to provide access to the web server. The DNS for the web server available only to the reverse proxy server and is not available to the user browser. Rather, the reverse proxy server acts to redirect certain requests to
specific web servers. Imagine you install the IWR gateway at http:\myserver\cognos\cgi-bin\cognos.cgi. Were the user to try to access that URL they would be told no such server (\myserver) existed. Instead, they would use the URL http:\proxyserver\cognos\cgi-bin\cognos.cgi. The reverse proxy server (\proxyserver) would redirect all requests to \proxyserver\cognos to \myserver\cognos. The effect of this is to make it impossible to attack the web server directly as it does not exist beyond the reverse proxy server which is acting as a firewall.
This is the theory… 8)
do you use IP addresses in the URL defined in Cognos configuration manager?
on all servers?
which gateway protocol do you use? cgi or isapi?
do you use SSO? if so disable it and try again
What does the cogserver.log or event log give more detailed information?
1&2. All the servers are using IP addresses for the URLs in Cognos Configuration Manager.
3. CGI Gateway Protocol
4. SSO is Disabled. -Authentication type is LDAP and Anonymous Access is disabled so users are automatically prompted for the LDAP namespace
5. I’m not seeing any relevant info in the logs. I do see the connection made on the proxy server in the Apache logs.
I enabled anonymous access but it did not resolve the issue.
I’m currently testing this on our development server(single server instance) so that I’m not interfering with our semi-production environment(ditributed server instance).
Since I’m working on our local network I have no problems when the server is “redirecting” to the internal IP. I do have someone not on our local network who is confirming that it is failing for them since they don’t have access to that network.
The environment URLs for both instances are as follows:
DMZ
Apache Proxy Server 148.xxx.xxx.31
-Currently passes to the Single Instance at 10.xx.xx.91
Server Farm
Distributed:
Gateway Server - 10.xx.xx.89
Dispatcher URL for Gate - http://10.xx.xx.88:9300/p2pd/servlet/dispatch
Controller URL for Gate - http://10.xx.xx.88:80/cognos8/controllerServer
CM Server - 10.xx.xx.87
External Dispatcher - http://10.xx.xx.87:9300/p2pd/servlet/dispatch
Internal Dispatcher - http://10.xx.xx.87:9300/p2pd/servlet/dispatch
Dispatch for ExApp - http://10.xx.xx.88:9300/p2pd/servlet/dispatch
Content Manager URI - http://10.xx.xx.87:9300/p2pd/servlet
Report Server - 10.xx.xx.88
Gateway URI - http://10.xx.xx.89:80/cognos8/cgi-bin/cognos.cgi
External Dispatcher - http://10.xx.xx.88:9300/p2pd/servlet/dispatch
Internal Dispatcher - http://10.xx.xx.88:9300/p2pd/servlet/dispatch
Dispatch for ExApp - http://10.xx.xx.88:9300/p2pd/servlet/dispatch
Content Manager URL - http://10.xx.xx.87:9300/p2pd/servlet
Content Store - 10.xx.xx.86
Sample Data DB - 10.xx.xx.90
Single:
CM/Gate/Rep - 10.xx.xx.91
Gateway URL - http://localhost:80/cognos8/cgi-bin/cognos.cgi
Dispatcher for Gate - http://localhost:9300/p2pd/servlet/dispatch/ext
Controller for Gate - http://localhost:80/cognos8/controllerServer
External Dispatcher - http://localhost:9300/p2pd/servlet/dispatch
Internal Dispatcher - http://localhost:9300/p2pd/servlet/dispatch
Dispatcher for ExApp - http://localhost:9300/p2pd/servlet/dispatch
Content Manager URL - http://localhost:9300/p2pd/servlet
I changed the localhost entries to IPs and also the gateway pointing to the 148 address but that hasn’t worked either.
Thanks for the help, and yes plenty of virtual resources available when running on a mainframe. I would hate to have to do this with physical hardware.
this is how your environment should be configured. (not certain about your gateway apache port)
Now you have to figure out where the error occurs.
does your cogserver.log or gatewayisapi.log give some more details?
or is a port or something else wrongly configured (port/url) in apache? (what does the log say)
do you see the Cognos splash screen? If not the cognosisapi.dll is not executed. Is script execution allowed in the cgi-bin directory allowed (check httpd.conf file). If the gateway url should change to http://10.xx.xx.91/cognos8/cgi-bin/cognosisapi.dll. The splash screen and the url expansion are picked up from the default.html or index.htm located in the /c8/webcontent directory.
can you send a screenshot the the error an external user get?
I enabled Full logging which makes cogserver.log much more difficult to read but I still don’t see anything that’s failing or changing. The apache access.log and error.log don’t seem to point to anything either.
Ports appear to be fine.
The user’s who are external don’t see the splash screen because when the URL changes to the internal 10.xx.xx.91 it fails because they don’t have access to that network(see attached jpeg). I’m not using the mod2_2_cognos.so because our OS is 64bit and there is a 32bit ELF Class error that occurs. This issue has only effected Framework Manager but we have a workaround for that. I really hope that isnt the issue.
I tried changing the default.htm and index.html files but nothing changed, which is also a bit odd.
I’ll keep adding stuff I try, bit tired right now and my eyes are gonna start bleeding if I look at that cogserver.log anymore.
Object not found!
The requested URL was not found on this server. The link on the referring page seems to be wrong or outdated. Please inform the author of that page about the error.
If you think this is a server error, please contact the webmaster.
We have a reverseproxy implementation and two Cognos servers Server 1 (Gateway, Content Manager, App) Server2 (Content(inactive), App).
The reverse proxy is used for SSL purpose, but while accessing the SSL url form outside it is showing the flash screen but doesn’t log in the user or prompts a user id password for the user.
in a non company machine a user can easily log in using either http and https.
I’ve implemented reverse proxy using apache , I’ve follwed all the steps mentioned in this thread.
Problem:First screen displays, rest of the pages are giving 404 page not found error (http://192.168.8.70/cognos8/cgi-bin/cognos8cgi-bin) url has additional “cognos8cgi-bin” if i remove this from url rest of the pages work perfectly
Do i need a RewriteRule? Please some one send me a sample rules
My current configuration is
ServerName trafficsrv
SetOutputFilter proxy-html
ProxyHTMLEnable On
ProxyHTMLExtended On
ProxyRequests Off
ProxyPreserveHost On
RewriteEngine On
ProxyPass / http://bisrv/
ProxyPassReverse / http://bisrv/
RewriteRule ^/(.*)$ http://bisrv/$1 [P]
ProxyHTMLEnable On
ProxyHTMLURLMap / /
RequestHeader unset Accept-Encoding
ProxyHTMLURLMap /
You have quite some resource to your expense… !