different versions on client/server
Moderators: chulett, rschirm, roy
different versions on client/server
An 11.5.0.1 client (Designer) is allowed to log into the 11.5.0.2 (with Service Pack 1) server with no warnings or errors provided. Is there a way to enforce that client versions must match the server version?
A couple reasons I am asking:
1. A client-tier security patch is required to avoid a vulnerability. If someone reinstalls a fresh client without the patch, we need to disallow connections from such unpatched clients. We actually ran into this back on version 8.7.
2. Even further back in the days of 7.5.1, 7.5.1A, and 7.5.1B, we ran into a client-tier situation involving the pre-compile step that somehow made differences as runtime with a job working successfully or not. It's been so long ago I forget if the version difference resulted in an aborted job or a job that produced incorrect results. In any case, the client version made a HUGE difference.
A couple reasons I am asking:
1. A client-tier security patch is required to avoid a vulnerability. If someone reinstalls a fresh client without the patch, we need to disallow connections from such unpatched clients. We actually ran into this back on version 8.7.
2. Even further back in the days of 7.5.1, 7.5.1A, and 7.5.1B, we ran into a client-tier situation involving the pre-compile step that somehow made differences as runtime with a job working successfully or not. It's been so long ago I forget if the version difference resulted in an aborted job or a job that produced incorrect results. In any case, the client version made a HUGE difference.
Choose a job you love, and you will never have to work a day in your life. - Confucius
Agreed.
And dang, I remember dealing with #2 back in the day. Specifically, a client patch that corrected a sequence job compilation issue... compile without the patch, job no workie, with the patch the generated code (which I think had something to do with looping) actually worked. Had to put an annotation on the canvas to that effect.
And dang, I remember dealing with #2 back in the day. Specifically, a client patch that corrected a sequence job compilation issue... compile without the patch, job no workie, with the patch the generated code (which I think had something to do with looping) actually worked. Had to put an annotation on the canvas to that effect.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Is the dsrpcservices file documented anywhere? It's a one-liner with no comments:
How would one limit clients--based on computer name, IP address, or other?
Code: Select all
dscs /opt/IBM/InformationServer/Server/DSEngine/bin/dsapi_server * TCP/IP 0 0
Choose a job you love, and you will never have to work a day in your life. - Confucius
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Field 1 is dscs (DataStage common service)
Field 2 is the pathname of the dsapi_server executable.
Field 3 is a comma-delimited list of IP addresses from which connection requests can be accepted.
Field 4 is the network protocol to be used (always TCP/IP)
I can't recall what fields 5 and 6 do, and am not presently in a position to research these. The file used to be documented in the DataStage Administrator course; I'm not sure if it still is.
Field 2 is the pathname of the dsapi_server executable.
Field 3 is a comma-delimited list of IP addresses from which connection requests can be accepted.
Field 4 is the network protocol to be used (always TCP/IP)
I can't recall what fields 5 and 6 do, and am not presently in a position to research these. The file used to be documented in the DataStage Administrator course; I'm not sure if it still is.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Thank you for the tips! I had searched the Support Portal, Knowledge Center, and DSXchange and come up empty.
Field 5 - no idea.
Field 6 - I found it corresponds with the DS Administrator's Inactivity timeout value.
Would the idea behind using the dsrpcservices file be to block people out until ensuring their client has the correct version, fix pack, service pack, and patch level?
If so, I suppose that would be similar to revoking suite security roles through the web console, and restoring them one at a time to each user once their levels were verified.
Unless I am missing something, it sounds like the bottom-line is that we have to implement a process in order to enforce version-matching. It cannot be enforced by the software itself. IBM Support was suggesting entering an enhancement request.
Field 5 - no idea.
Field 6 - I found it corresponds with the DS Administrator's Inactivity timeout value.
Would the idea behind using the dsrpcservices file be to block people out until ensuring their client has the correct version, fix pack, service pack, and patch level?
If so, I suppose that would be similar to revoking suite security roles through the web console, and restoring them one at a time to each user once their levels were verified.
Unless I am missing something, it sounds like the bottom-line is that we have to implement a process in order to enforce version-matching. It cannot be enforced by the software itself. IBM Support was suggesting entering an enhancement request.
Choose a job you love, and you will never have to work a day in your life. - Confucius