<commit_before>// Module included in the following assemblies:
//
// * support/gathering-cluster-data.adoc

[id="support-generating-a-sosreport-archive_{context}"]
= Generating a sosreport archive for an {product-title} cluster node

The recommended way to generate a `sosreport` for an {product-title} {product-version} cluster node is through a debug pod.

.Prerequisites

* You have access to the cluster as a user with the `cluster-admin` role.
* You have SSH access to your hosts.
* You have installed the OpenShift CLI (`oc`).
* You have a Red Hat standard or premium Subscription.
* You have a Red Hat Customer Portal account.
* You have an existing Red Hat Support case ID.

.Procedure

. Obtain a list of cluster nodes:
+
[source,terminal]
----
$ oc get nodes
----

. Enter into a debug session on the target node. This step instantiates a debug pod called `<node_name>-debug`:
+
[source,terminal]
----
$ oc debug node/my-cluster-node
----

. Set `/host` as the root directory within the debug shell. The debug pod mounts the host's root file system in `/host` within the pod. By changing the root directory to `/host`, you can run binaries contained in the host's executable paths:
+
[source,terminal]
----
# chroot /host
----
+
[NOTE]
====
{product-title} {product-version} cluster nodes running {op-system-first} are immutable and rely on Operators to apply cluster changes. Accessing cluster nodes using SSH is not recommended and nodes will be tainted as _accessed_. However, if the {product-title} API is not available, or the kubelet is not properly functioning on the target node, `oc` operations will be impacted. In such situations, it is possible to access nodes using `ssh core@<node>.<cluster_name>.<base_domain>` instead.
====

. Start a `toolbox` container, which includes the required binaries and plug-ins to run `sosreport`:
+
[source,terminal]
----
# toolbox<commit_msg>BZ1967977: generate sos report when a node has taint with NoExecute configuration<commit_after>// Module included in the following assemblies:
//
// * support/gathering-cluster-data.adoc

[id="support-generating-a-sosreport-archive_{context}"]
= Generating a sosreport archive for an {product-title} cluster node

The recommended way to generate a `sosreport` for an {product-title} {product-version} cluster node is through a debug pod.

.Prerequisites

* You have access to the cluster as a user with the `cluster-admin` role.
* You have SSH access to your hosts.
* You have installed the OpenShift CLI (`oc`).
* You have a Red Hat standard or premium Subscription.
* You have a Red Hat Customer Portal account.
* You have an existing Red Hat Support case ID.

.Procedure

. Obtain a list of cluster nodes:
+
[source,terminal]
----
$ oc get nodes
----

. Enter into a debug session on the target node. This step instantiates a debug pod called `<node_name>-debug`:
+
[source,terminal]
----
$ oc debug node/my-cluster-node
----
+
To enter into a debug session on the target node that is tainted with the `NoExecute` effect, add a toleration to a dummy namespace, and start the debug pod in the dummy namespace:
+
[source,terminal]
----
$ oc new-project dummy
----
+
[source,terminal]
----
$ oc patch namespace dummy --type=merge -p '{"metadata": {"annotations": { "scheduler.alpha.kubernetes.io/defaultTolerations": "[{\"operator\": \"Exists\"}]"}}}'
----
+
[source,terminal]
----
$ oc debug node/my-cluster-node
----
+
. Set `/host` as the root directory within the debug shell. The debug pod mounts the host's root file system in `/host` within the pod. By changing the root directory to `/host`, you can run binaries contained in the host's executable paths:
+
[source,terminal]
----
# chroot /host
----
+
[NOTE]
====
{product-title} {product-version} cluster nodes running {op-system-first} are immutable and rely on Operators to apply cluster changes. Accessing cluster nodes using SSH is not recommended and nodes will be tainted as _accessed_. However, if the {product-title} API is not available, or the kubelet is not properly functioning on the target node, `oc` operations will be impacted. In such situations, it is possible to access nodes using `ssh core@<node>.<cluster_name>.<base_domain>` instead.
====

. Start a `toolbox` container, which includes the required binaries and plug-ins to run `sosreport`:
+
[source,terminal]
----
# toolbox
{'fraction_non_alphanumeric': 0.10861079219288175, 'fraction_numerical': 0.0016073478760045925, 'mean_word_length': 4.041666666666667, 'pattern_counts': {'":': 4, '<': 11, '<?xml version=': 0, '>': 11, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4224286', 'n_tokens_mistral': 1268, 'n_tokens_neox': 1209, 'n_words': 565}