AIX

Hi!

Does anyone know, how long IBM provides support for a certain AIX Service Pack?  I only found the AIX support lifecycle for tecnology levels.

My actual problem:  We have a system, which is currently on oslevel 7200-05-03-2148.  We can't upgrade it to TL5 SP7, as that would break some software we use there requiring the ancient openssl 0.9.8 - which is no longer available on SP7.

Luckily it is foreseeable, that we can decommission the server in about a year.  The only question would be, if we would still receive support / security fixes for SP6 (or even SP3) till then.

Hi!

Does anyone know, how long IBM provides support for a certain AIX Service Pack?  I only found the AIX support lifecycle for tecnology levels.

My actual problem:  We have a system, which is currently on oslevel 7200-05-03-2148.  We can't upgrade it to TL5 SP7, as that would break some software we use there requiring the ancient openssl 0.9.8 - which is no longer available on SP7.

Luckily it is foreseeable, that we can decommission the server in about a year.  The only question would be, if we would still receive support / security fixes for SP6 (or even SP3) till then.

Hi!

Does anyone know, how long IBM provides support for a certain AIX Service Pack?  I only found the AIX support lifecycle for tecnology levels.

My actual problem:  We have a system, which is currently on oslevel 7200-05-03-2148.  We can't upgrade it to TL5 SP7, as that would break some software we use there requiring the ancient openssl 0.9.8 - which is no longer available on SP7.

Luckily it is foreseeable, that we can decommission the server in about a year.  The only question would be, if we would still receive support / security fixes for SP6 (or even SP3) till then.

As Bertram wrote, you must order fixes through IBM support for earlier SPs.

Optimizing Lech's solution, you can copy libssl.a and libcrypto*.a to the directory with your application and write a small wrapper script like:

export LIBPATH=/path/to/my/old/openssl

start_app

By setting LIBPATH variable you redefine where the application will search for libraries. Just don't do it globally in /etc/environment, but only for the application start.

https://www.ibm.com/support/pages/libpath-environment-variables-aix-platforms

Hi!

Does anyone know, how long IBM provides support for a certain AIX Service Pack?  I only found the AIX support lifecycle for tecnology levels.

My actual problem:  We have a system, which is currently on oslevel 7200-05-03-2148.  We can't upgrade it to TL5 SP7, as that would break some software we use there requiring the ancient openssl 0.9.8 - which is no longer available on SP7.

Luckily it is foreseeable, that we can decommission the server in about a year.  The only question would be, if we would still receive support / security fixes for SP6 (or even SP3) till then.

Beware of possible side effects.

Archives libssl.a and libcrypto*.a contain more than *0.8.9.so files. Suppose we do what you proposed and later we install an efix for OpenSSL. It could change files in /usr/lib/, but of course will not change copies of these files in /path/to/my/old/openssl. So if dynamic linker loading the application (or any other binary this application wants to spawn/exec) wants to load some other OpenSSL library it will pick up the unpatched copy in /path/to/my/old/openssl, not the patched copy in /usr/lib (as contents of LIBPATH takes precedence over the standard library search path).

As Bertram wrote, you must order fixes through IBM support for earlier SPs.

Optimizing Lech's solution, you can copy libssl.a and libcrypto*.a to the directory with your application and write a small wrapper script like:

export LIBPATH=/path/to/my/old/openssl

start_app

By setting LIBPATH variable you redefine where the application will search for libraries. Just don't do it globally in /etc/environment, but only for the application start.

https://www.ibm.com/support/pages/libpath-environment-variables-aix-platforms

Hi!

Does anyone know, how long IBM provides support for a certain AIX Service Pack?  I only found the AIX support lifecycle for tecnology levels.

My actual problem:  We have a system, which is currently on oslevel 7200-05-03-2148.  We can't upgrade it to TL5 SP7, as that would break some software we use there requiring the ancient openssl 0.9.8 - which is no longer available on SP7.

Luckily it is foreseeable, that we can decommission the server in about a year.  The only question would be, if we would still receive support / security fixes for SP6 (or even SP3) till then.

This is exactly the reason why you shouldn't define LIBPATH globally or in a user's profile. Only for the application you need.

P.S. You can't expect seriously an efix for OpenSSL 0.9.8 which is out of date since many years. 

Beware of possible side effects.

Archives libssl.a and libcrypto*.a contain more than *0.8.9.so files. Suppose we do what you proposed and later we install an efix for OpenSSL. It could change files in /usr/lib/, but of course will not change copies of these files in /path/to/my/old/openssl. So if dynamic linker loading the application (or any other binary this application wants to spawn/exec) wants to load some other OpenSSL library it will pick up the unpatched copy in /path/to/my/old/openssl, not the patched copy in /usr/lib (as contents of LIBPATH takes precedence over the standard library search path).

As Bertram wrote, you must order fixes through IBM support for earlier SPs.

Optimizing Lech's solution, you can copy libssl.a and libcrypto*.a to the directory with your application and write a small wrapper script like:

export LIBPATH=/path/to/my/old/openssl

start_app

By setting LIBPATH variable you redefine where the application will search for libraries. Just don't do it globally in /etc/environment, but only for the application start.

https://www.ibm.com/support/pages/libpath-environment-variables-aix-platforms

Hi!

Does anyone know, how long IBM provides support for a certain AIX Service Pack?  I only found the AIX support lifecycle for tecnology levels.

My actual problem:  We have a system, which is currently on oslevel 7200-05-03-2148.  We can't upgrade it to TL5 SP7, as that would break some software we use there requiring the ancient openssl 0.9.8 - which is no longer available on SP7.

Luckily it is foreseeable, that we can decommission the server in about a year.  The only question would be, if we would still receive support / security fixes for SP6 (or even SP3) till then.

> P.S. You can't expect seriously an efix for OpenSSL 0.9.8 which is out of date since many years.

I am talkig about efixes not for 0.8.9, but for newer versions (that happen to be inside the *.a files copied to /path/to/my/old).

> This is exactly the reason why you shouldn't define LIBPATH globally or in a user's profile. Only for the application you need.

Exported LIBPATH will be used also by any processess spawned/executed by your apllication. Some of these might be using OpenSSL libraries newer than 0.8.9 - and these ones will use not the patched copies in /usr/lib, but the unpatched copies in /path/to/my/old.

This is exactly the reason why you shouldn't define LIBPATH globally or in a user's profile. Only for the application you need.

P.S. You can't expect seriously an efix for OpenSSL 0.9.8 which is out of date since many years. 

Beware of possible side effects.

Archives libssl.a and libcrypto*.a contain more than *0.8.9.so files. Suppose we do what you proposed and later we install an efix for OpenSSL. It could change files in /usr/lib/, but of course will not change copies of these files in /path/to/my/old/openssl. So if dynamic linker loading the application (or any other binary this application wants to spawn/exec) wants to load some other OpenSSL library it will pick up the unpatched copy in /path/to/my/old/openssl, not the patched copy in /usr/lib (as contents of LIBPATH takes precedence over the standard library search path).

As Bertram wrote, you must order fixes through IBM support for earlier SPs.

Optimizing Lech's solution, you can copy libssl.a and libcrypto*.a to the directory with your application and write a small wrapper script like:

export LIBPATH=/path/to/my/old/openssl

start_app

By setting LIBPATH variable you redefine where the application will search for libraries. Just don't do it globally in /etc/environment, but only for the application start.

https://www.ibm.com/support/pages/libpath-environment-variables-aix-platforms

Hi!

Does anyone know, how long IBM provides support for a certain AIX Service Pack?  I only found the AIX support lifecycle for tecnology levels.

My actual problem:  We have a system, which is currently on oslevel 7200-05-03-2148.  We can't upgrade it to TL5 SP7, as that would break some software we use there requiring the ancient openssl 0.9.8 - which is no longer available on SP7.

Luckily it is foreseeable, that we can decommission the server in about a year.  The only question would be, if we would still receive support / security fixes for SP6 (or even SP3) till then.

> I am talkig about efixes not for 0.8.9, but for newer versions (that happen to be inside the *.a files copied to /path/to/my/old).

If you copied files outisde of the standard path, how would AIX (installp/emgr) find it there? They will not be touched by emgr and you can freely install newer OpenSSL versions. The older libraries will not be affected by any update or efix anyway.

> Exported LIBPATH will be used also by any processess spawned/executed by your apllication.

Yes, it is so. The new forked process inherits the environment of the parent process unless something else is specified. 

> P.S. You can't expect seriously an efix for OpenSSL 0.9.8 which is out of date since many years.

I am talkig about efixes not for 0.8.9, but for newer versions (that happen to be inside the *.a files copied to /path/to/my/old).

> This is exactly the reason why you shouldn't define LIBPATH globally or in a user's profile. Only for the application you need.

Exported LIBPATH will be used also by any processess spawned/executed by your apllication. Some of these might be using OpenSSL libraries newer than 0.8.9 - and these ones will use not the patched copies in /usr/lib, but the unpatched copies in /path/to/my/old.

This is exactly the reason why you shouldn't define LIBPATH globally or in a user's profile. Only for the application you need.

P.S. You can't expect seriously an efix for OpenSSL 0.9.8 which is out of date since many years. 

Beware of possible side effects.

Archives libssl.a and libcrypto*.a contain more than *0.8.9.so files. Suppose we do what you proposed and later we install an efix for OpenSSL. It could change files in /usr/lib/, but of course will not change copies of these files in /path/to/my/old/openssl. So if dynamic linker loading the application (or any other binary this application wants to spawn/exec) wants to load some other OpenSSL library it will pick up the unpatched copy in /path/to/my/old/openssl, not the patched copy in /usr/lib (as contents of LIBPATH takes precedence over the standard library search path).

As Bertram wrote, you must order fixes through IBM support for earlier SPs.

Optimizing Lech's solution, you can copy libssl.a and libcrypto*.a to the directory with your application and write a small wrapper script like:

export LIBPATH=/path/to/my/old/openssl

start_app

By setting LIBPATH variable you redefine where the application will search for libraries. Just don't do it globally in /etc/environment, but only for the application start.

https://www.ibm.com/support/pages/libpath-environment-variables-aix-platforms

Hi!

Does anyone know, how long IBM provides support for a certain AIX Service Pack?  I only found the AIX support lifecycle for tecnology levels.

My actual problem:  We have a system, which is currently on oslevel 7200-05-03-2148.  We can't upgrade it to TL5 SP7, as that would break some software we use there requiring the ancient openssl 0.9.8 - which is no longer available on SP7.

Luckily it is foreseeable, that we can decommission the server in about a year.  The only question would be, if we would still receive support / security fixes for SP6 (or even SP3) till then.