parallel deployment http(s) configuration problem ....load balanced

Load Balanced portal configuration problem / question.

In a new luminis go live, we configured a BIGIP F5 for load balancing by
allowing http(s) traffic to pass through to port 80 on the portal tier
servers (as specified in the parallel deployment guide...top of pg. 1-4).
Everything seems to work great in this http "passthrough" configuration
except we started getting these continual insecure errors inside cp.log
on the tier servers.
[2010-02-14 07:24:31,942] [ERROR](SecureRedirector.java:310) {http-80-Processor20} [com.pipeline.web.SecureRedirector]: Access security violation:[
        GET /cp/home/check/pre
        Referer: http://my.unm.edu/
        Mode: insecure
        Requestor: 75.173.153.57
]

They appeared to be coming from ISPs who had cached access to the portal and
were very frequent, filling up cp logs.

The only fix we came up with was to redirect all port 80 traffic to port 443
and allow server side ssl at the load balancer.  Most everything works,
except we have at least one odd error where the calendar using safari
browser times out with an https error.

But the real issue is, this is not the correct Load balancer configuration.
Does anyone have an idea how we could fix this and go back to the http
passthrough config at the load balancer?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

possible answer

I opened a sungard ticket and they referenced this faq: 1-3NYOQW

I will be testing this as well another lumdev posting that discusses the redirector errors.

-d

pd config problem

 Just so you know, those Access Security violations are common place in most school's cp.logs

We are live on PD, working fine behind two F5's, and still see 

ine.web.SecureRedirector]: Access security violation:[

        GET /cp/home/displaylogin

        Referer: http://my.pcc.edu/cp/home/loginf

 
SSL cert is on the F5, 80 and 443 traffic inbound on the F5 is sent back to luminis to port 80 only.  How does it act when you login?  Does it get to part of the login process than halt? Where does it stop or error?
 
 Things to check are:
 
Are you sure your configman settings are correct?  fos.enabled true? check all your fos.*  (on a side note, we didn't bother using the fos.server.cookie's to hold stickiness, we just used the built in F5 http stickiness).
 
Does each web server have local.host local.fqn, etc.. set for that server in the site category?  The configman -s local.host mywebserver1.myschool.edu -c site -h, etc..
 
Do you have webserver.port.list and webserver.host.list correct?  If you have 4 web servers, it should look like 80,80,80,80 and web1, web2, web3, web4, respectively.
 
After that, it is probably time to start focusing on your network stuff.  Are the web servers using the F5 as their default gateway (kinda depends on how to set things up)?  Stuff like that.
 
 

 

insecure errors

The portal login is fully functional, but we are getting anywhere up to 20k insecure messages per hour.   We've changed the websecure.all.xml to add some opt or true secure labels, but no effect.    We still need to try the change someone suggested to set web.secure.access.enforce=true inside the $CP_WEBINF/lib/cp.jar,
in the file com/pipeline/web/SecureURLMap.properties   (but, with fos.enabled=true will this have any affect?)

Sungard suggested to flush the classcache, which I think means to do an rm -rf $CP_WEB_ROOT/work/Catalina/localhost/_/org/apache/jsp/jsp/*     and then a full restart.

They also said to run cpfixurls, but not sure if we should run this again or what it actually does.   We are full-SSl enabled.

thanks, -d
 

classcache

there is a "compilejsp" command available to the luminis admin shell user.

this probably even deletes the class cache first

Think it will require a restart though.

Derek
University of Leeds, UK

pd config problem

THanks for your ideas.  Everything seems to be set up correctly.  I have tried changing websecure.all.xml, but that doesnt seem to have any effect.  This morning our logs are rotating every 5 minutes with ~30k insecure entries, (mostly timedout.jsp errors) from various ip addresses including user desktops.   Seems as soon as some connects (or disconnects??) their desktop continually pounds on server with these insecure entries.  

I have not yet, followed a suggestion from lumdev.net to "set web.secure.access.enforce=true inside the $CP_WEBINF/lib/cp.jar,
in the file com/pipeline/web/SecureURLMap.properties"   because other docs (FAQ 1-3NYOQW), say: "in PD environments, where fos.enabled=true, the
secureURLMap is overridden such that insecure http:// requests are allowed on the
portal tiers (since SSL traffic is terminated at the load balancer)."

The portal is fully functional, except we are getting slammed with these errors.   To make changes I generally have to take the production portal down, which requires scheduling emergency changes.....so I would like to make smart changes and not make guesses.

Any ideas??  or any ideas on debugging this.....i really dont understand the level of traffic for these insecure errors.

thanks,

 -drex