WebSpeed installation problem

Posted by teppo_55 on 29-Jun-2016 03:41


Installing new OpenEdge version caused a production halt in mission critical WebSpeed application!  This should be corrected.

Customer had used default cgiip script file (wspd_cgi.sh) to connect WebSpeed broker from web browsers.

Now installing new versio (11.6) into same machine, this file was replaced by new file with new OE version and default WebSpeed broker name.   This caused a production halt in mission critical WebSpeed application.

Note: WebSpeed installation does not warn this behavior.

Of course the usage of default file wspd_cgi.sh is not best practise, but installation process should
- not replace the file, if it exists
- ask, if this file will be replaced


- teppo

All Replies

Posted by bronco on 29-Jun-2016 04:15

Didn't you test it before you went to production?

Posted by teppo_55 on 29-Jun-2016 04:52

This was OpenEdge version installation, which should not touch older production version.
- teppo
Teppo Määttänen____| TR-Tiimi Oy
Consultant_________| Struerintie 1
teppo @ trtiimi.fi____| 30100 FORSSA
int-358-50-5748 226 | www.trtiimi.fi

Posted by Roy Ellis on 29-Jun-2016 05:35


some points about this:

1) Using the original script name is more than just not following best practice it is a HUGE security hole.  Someone can search for wspd_cgi.sh and find sites that are not correctly configured and do serious damage.  When I taught WebSpeed security I used to show this hole regularly.

2) The install asks you where it should copy the messenger script and you must give your web server cgi directory to the install program.  The install program does not know the location of your web server install. If you don't want to over-write your production location you can simply copy the messenger to another directory (like $WRKDIR).

3) Testing before running an install on an production machine is a very important step.

4) Even thought I disagree that this is a bug, I am not the final say on this subject.  If you believe this is a bug, the correct way to ensure a bug is entered is to open a Tech Support request so they can add the bug.  The bug will be evaluated by the install team and priority set.



Posted by teppo_55 on 29-Jun-2016 05:58

In this case this is not a security hole, because this application doesn’t work in Internet but in a LAN. 
You are right that this configuration is very bad, and we are going to change it.  It is easy to rename wspd_cgi.sh, but unfortunetely changes must be made in browser clients.  My customer will not suffer of this installation “feature” after this change.
My goal is to make sure that nobody in the world will make this same mistake.
I think that we agree on the principle that installing a newer OpenEdge version into a machine should NOT touch running older applications – in any case.
Regards and thanks
- teppo
Teppo Määttänen____| TR-Tiimi Oy
Consultant_________| Struerintie 1
teppo @ trtiimi.fi____| 30100 FORSSA
int-358-50-5748 226 | www.trtiimi.fi

Posted by Bill Wood on 29-Jun-2016 06:36

On your point #4 -- installing two versions should not stomp on each other.

OpenEdge does make an effort to do this. That is why different versions use different install directories and different names for registry entries.

The case you are talking about is that the new installation pointed to a web server in common with the old installation and in the install you said you did want to copy the WebSpeed cgi files to that web server.

We have also had comments from many people that they don't want to have each cgi-bin and each URL going to WebSpeed to be "versioned". No one has wanted the URL to have a different format each version of OpenEdge. This "feature" goes back to the second version of WebSpeed.

I agree that the default installation should not overwrite an old installation, but I also think that if a customer explicitly points to a common location the OpenEdge installer should honor that.

But your first point was that the documentation should be clearer if this is what is happening and perhaps the installer should check and warn in this case. Both those make sense.

This thread is closed