IBM Security Verify

What are methods to enable / disable GSKit tracing on lightweight containers?

In the past, we could either set the options in the webseal configuration or we could use isam_cli logs ssl -c enable proxy-instance

Then the gskit trace events went to the logging directory for the Web reverse proxy instance and was named ssl_trace.log.

If we enable/disable with a webseal configuration change and restart the container to pick up the latest published configuration, with the lightweight containers, as soon as they are restarted the overlay filesystem on OpenShift disappears, so all trace data is lost.  Hence, it would be best to have something like the isam_cli logs ssl command.  Is there such an option in wrpadmin or some other binary on the lightweight containers, or should I open an idea?  This seems like an important thing to require based on how often L2 asked for gskit traces for various issues.

The same question goes for routing traces.  We haven't had to do this in a long time.  But if we did now with the lightweight containers, the trace data would be lost as soon as the container restarts.  Enabling/disabling on a live container would be better so they could be collected before the container restarts.

Also, just to head off the question, yes, we could attach a persistent volume to the container temporarily.  However, on production systems, altering our statefulset/deployment app configuration to add the persistent volume is going to be frowned on, in conjunction with the fact that it requires a restart of the pod/container and hence causes an outage as a webseal restart would.

In summary, is a gskit trace and/or a routing trace without restarting the webseal process on lightweight containers possible?  If so, how is each done?  If not, does anyone else think this would be a good idea canidiate?

Thanks for your thoughts!

------------------------------
Matt Jenkins
------------------------------

Original Message:
Sent: 1/25/2023 1:25:00 PM
From: Matt Jenkins
Subject: Does the ability to perform a GSKit or routing trace on webseal running as lightweight containers exist?

What are methods to enable / disable GSKit tracing on lightweight containers?

In the past, we could either set the options in the webseal configuration or we could use isam_cli logs ssl -c enable proxy-instance

Then the gskit trace events went to the logging directory for the Web reverse proxy instance and was named ssl_trace.log.

If we enable/disable with a webseal configuration change and restart the container to pick up the latest published configuration, with the lightweight containers, as soon as they are restarted the overlay filesystem on OpenShift disappears, so all trace data is lost.  Hence, it would be best to have something like the isam_cli logs ssl command.  Is there such an option in wrpadmin or some other binary on the lightweight containers, or should I open an idea?  This seems like an important thing to require based on how often L2 asked for gskit traces for various issues.

The same question goes for routing traces.  We haven't had to do this in a long time.  But if we did now with the lightweight containers, the trace data would be lost as soon as the container restarts.  Enabling/disabling on a live container would be better so they could be collected before the container restarts.

Also, just to head off the question, yes, we could attach a persistent volume to the container temporarily.  However, on production systems, altering our statefulset/deployment app configuration to add the persistent volume is going to be frowned on, in conjunction with the fact that it requires a restart of the pod/container and hence causes an outage as a webseal restart would.

In summary, is a gskit trace and/or a routing trace without restarting the webseal process on lightweight containers possible?  If so, how is each done?  If not, does anyone else think this would be a good idea canidiate?

Thanks for your thoughts!

------------------------------
Matt Jenkins
------------------------------

@Scott Exton, how would we manually send a SIGUSR1?  We can't do that from the OpenShift remoteshell (oc rsh) can we?  I expect we'd need to do it as root on the OCP 3 box but I am not sure how that would happen on OCP4 (we are just starting to deploy on OCP v4).

Understood about the routing events for messages and serviceability.  I suppose they have always been a deploy config and restart webseal so we'll likely just need to accept that.  But gskit is one I would like to figure out, either if we can send SIGUSR1 ourselves or if I need to open an idea.

Thanks very much!

Matt​

------------------------------
Matt Jenkins
------------------------------

Original Message:
Sent: Thu January 26, 2023 05:16 PM
From: Scott Exton
Subject: Does the ability to perform a GSKit or routing trace on webseal running as lightweight containers exist?

Matt,

 

Unfortunately there is not an easy way to dynamically enable GSKit tracing in the lightweight containers – this is something which should really be added and so if you could raise an enhancement request for the capability it would be appreciated.  The good news is that the isam_cli command which you mentioned simply sends a SIGUSR1 signal to the WebSEAL process in order to enable GSKit tracing.  So, if you manually send the SIGUSR1 signal to the WebSEAL process within the lightweight container it should enable GSKit tracing.

 

The routing file currently handles the logging for two types of messages, serviceability messages along with debug trace messages.  The later can be dynamically managed using the wrpadmin utility, which can be found in the WebSEAL lightweight container.  The former is statically configured, and so you would need to restart the container if you wished to reconfigure any of the serviceability message routes.

 

I hope that this helps.

 

Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor

image002.png@01D85F83.85516C50">

 

 

 

Original Message:
Sent: 1/25/2023 1:25:00 PM
From: Matt Jenkins
Subject: Does the ability to perform a GSKit or routing trace on webseal running as lightweight containers exist?

What are methods to enable / disable GSKit tracing on lightweight containers?

In the past, we could either set the options in the webseal configuration or we could use isam_cli logs ssl -c enable proxy-instance

Then the gskit trace events went to the logging directory for the Web reverse proxy instance and was named ssl_trace.log.

If we enable/disable with a webseal configuration change and restart the container to pick up the latest published configuration, with the lightweight containers, as soon as they are restarted the overlay filesystem on OpenShift disappears, so all trace data is lost.  Hence, it would be best to have something like the isam_cli logs ssl command.  Is there such an option in wrpadmin or some other binary on the lightweight containers, or should I open an idea?  This seems like an important thing to require based on how often L2 asked for gskit traces for various issues.

The same question goes for routing traces.  We haven't had to do this in a long time.  But if we did now with the lightweight containers, the trace data would be lost as soon as the container restarts.  Enabling/disabling on a live container would be better so they could be collected before the container restarts.

Also, just to head off the question, yes, we could attach a persistent volume to the container temporarily.  However, on production systems, altering our statefulset/deployment app configuration to add the persistent volume is going to be frowned on, in conjunction with the fact that it requires a restart of the pod/container and hence causes an outage as a webseal restart would.

In summary, is a gskit trace and/or a routing trace without restarting the webseal process on lightweight containers possible?  If so, how is each done?  If not, does anyone else think this would be a good idea canidiate?

Thanks for your thoughts!

------------------------------
Matt Jenkins
------------------------------

Original Message:
Sent: 1/26/2023 5:25:00 PM
From: Matt Jenkins
Subject: RE: Does the ability to perform a GSKit or routing trace on webseal running as lightweight containers exist?

@Scott Exton, how would we manually send a SIGUSR1?  We can't do that from the OpenShift remoteshell (oc rsh) can we?  I expect we'd need to do it as root on the OCP 3 box but I am not sure how that would happen on OCP4 (we are just starting to deploy on OCP v4).

Understood about the routing events for messages and serviceability.  I suppose they have always been a deploy config and restart webseal so we'll likely just need to accept that.  But gskit is one I would like to figure out, either if we can send SIGUSR1 ourselves or if I need to open an idea.

Thanks very much!

Matt​

------------------------------
Matt Jenkins
------------------------------

Original Message:
Sent: Thu January 26, 2023 05:16 PM
From: Scott Exton
Subject: Does the ability to perform a GSKit or routing trace on webseal running as lightweight containers exist?

Matt,

 

Unfortunately there is not an easy way to dynamically enable GSKit tracing in the lightweight containers – this is something which should really be added and so if you could raise an enhancement request for the capability it would be appreciated.  The good news is that the isam_cli command which you mentioned simply sends a SIGUSR1 signal to the WebSEAL process in order to enable GSKit tracing.  So, if you manually send the SIGUSR1 signal to the WebSEAL process within the lightweight container it should enable GSKit tracing.

 

The routing file currently handles the logging for two types of messages, serviceability messages along with debug trace messages.  The later can be dynamically managed using the wrpadmin utility, which can be found in the WebSEAL lightweight container.  The former is statically configured, and so you would need to restart the container if you wished to reconfigure any of the serviceability message routes.

 

I hope that this helps.

 

Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor

image002.png@01D85F83.85516C50">

 

 

 

Original Message:
Sent: 1/25/2023 1:25:00 PM
From: Matt Jenkins
Subject: Does the ability to perform a GSKit or routing trace on webseal running as lightweight containers exist?

What are methods to enable / disable GSKit tracing on lightweight containers?

In the past, we could either set the options in the webseal configuration or we could use isam_cli logs ssl -c enable proxy-instance

Then the gskit trace events went to the logging directory for the Web reverse proxy instance and was named ssl_trace.log.

If we enable/disable with a webseal configuration change and restart the container to pick up the latest published configuration, with the lightweight containers, as soon as they are restarted the overlay filesystem on OpenShift disappears, so all trace data is lost.  Hence, it would be best to have something like the isam_cli logs ssl command.  Is there such an option in wrpadmin or some other binary on the lightweight containers, or should I open an idea?  This seems like an important thing to require based on how often L2 asked for gskit traces for various issues.

The same question goes for routing traces.  We haven't had to do this in a long time.  But if we did now with the lightweight containers, the trace data would be lost as soon as the container restarts.  Enabling/disabling on a live container would be better so they could be collected before the container restarts.

Also, just to head off the question, yes, we could attach a persistent volume to the container temporarily.  However, on production systems, altering our statefulset/deployment app configuration to add the persistent volume is going to be frowned on, in conjunction with the fact that it requires a restart of the pod/container and hence causes an outage as a webseal restart would.

In summary, is a gskit trace and/or a routing trace without restarting the webseal process on lightweight containers possible?  If so, how is each done?  If not, does anyone else think this would be a good idea canidiate?

Thanks for your thoughts!

------------------------------
Matt Jenkins
------------------------------