unixPB: adds `become: true` to all kernel config related tasks

[mahdipub]

in macos, touching /etc/sysctl.conf, puting content in it or rebooting system is what needs scallated priviledge because most of the time ansible user does not have enought authority to do system changes and need to use sudo. Adding become: true guarantee that ansible will not fail due to priviledge issue.

Sigend-off-by: [email protected]

Checklist

• [x] commit message has one of the standard prefixes
• [ ] faq.md updated if appropriate
• [ ] other documentation is changed or added (if applicable)
• [ ] playbook changes run through VPC or QPC (if you have access)
• [ ] VPC/QPC not applicable for this PR
• [ ] for inventory.yml changes, bastillion/nagios/jenkins updated accordingly

[mahdipub]

Can we add a comment why

Comment updated

[sxa]

@Haroon-Khel @gdams I'd appreciate your input on this in case there's any chance if it causing problems inside our infrastructure.

[Haroon-Khel]

Adding become: true guarantee that ansible will not fail due to priviledge issue.

Do we have instances of it failing due to lack of privilege?

[mahdipub]

Adding become: true guarantee that ansible will not fail due to priviledge issue.

Do we have instances of it failing due to lack of privilege?

Here is a sample failure.

TASK [../AdoptOpenJDK_Unix_Playbook/roles/common : Writing kernel tuning parameters to /etc/sysctl.conf] ***************************************************************************************************
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: PermissionError: [Errno 13] Permission denied: b'/Users/j9admin/.ansible/tmp/ansible-tmp-1727390025.62139-15462-277057472900612/tmpjpocvkr7' -> b'/private/etc/sysctl.conf'
fatal: [xxxx.xxx.xxxx.com]: FAILED! => {"changed": false, "msg": "The destination directory (/private/etc) is not writable by the current user. Error was: [Errno 13] Permission denied: b'/private/etc/.ansible_tmpff7031_ksysctl.conf'"}

[sxa]

Adding become: true guarantee that ansible will not fail due to priviledge issue.

Do we have instances of it failing due to lack of privilege?

Here is a sample failure.

TASK [../AdoptOpenJDK_Unix_Playbook/roles/common : Writing kernel tuning parameters to /etc/sysctl.conf] ***************************************************************************************************
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: PermissionError: [Errno 13] Permission denied: b'/Users/j9admin/.ansible/tmp/ansible-tmp-1727390025.62139-15462-277057472900612/tmpjpocvkr7' -> b'/private/etc/sysctl.conf'
fatal: [xxxx.xxx.xxxx.com]: FAILED! => {"changed": false, "msg": "The destination directory (/private/etc) is not writable by the current user. Error was: [Errno 13] Permission denied: b'/private/etc/.ansible_tmpff7031_ksysctl.conf'"}

@mahdipub Can you give some information about the environment where you are seeing this - are you running ansible to set up the machine locally and using a normal user that can elevate it's privileges with sudo or similar?

[mahdipub]

@mahdipub Can you give some information about the environment where you are seeing this - are you running ansible to set up the machine locally and using a normal user that can elevate it's privileges with sudo or similar?

@sxa in provided output, I am running against a mac machine remotely (from my laptop) and the user as you said is not privileged and need sudo to escalate but has sudo rights.

[karianna]

Can we add a comment why

Comment updated

Sorry, I meant within the code :-)

[sxa]

@Haroon-Khel Can you easily verify that this won't negatively impact our playbook executions from ansible?

[mahdipub]

Can we add a comment why

Comment updated

Sorry, I meant within the code :-)

@karianna, from my point on the discussion here, I think the changes in this PR will be obvious when become in effect. Then a comment may only cause confusion.

[karianna]

@mahdipub Have you signed the Eclipse CLA? That check seems to be failing.

[mahdipub]

@mahdipub Have you signed the Eclipse CLA? That check seems to be failing.

I did. I tried JIC once more and I got:

The email address [email protected] is already registered.

[smlambert]

[Haroon-Khel]

Can you easily verify that this won't negatively impact our playbook executions from ansible?

I dont think I can easily verify this. Unfortunately the macos pr check doesnt run kernel_tuning tasks, so only the core_dumps tagged task ran

TASK [Common : Allow staff users to generate core dumps] ***********************
changed: [localhost]

I think the changes are ok, since they ultimately give the playbook execution a privilege it is expecting (or should otherwise have when running those tasks)

[mahdipub]

There was a typo in signed-off line. I have changed that. Hopefully that would help cover the issue.

[karianna]

I think the macos13 failure is unrelated, but not sure.

[Haroon-Khel]

Ive restarted the macos13 job

[karianna]

Ive restarted the macos13 job

It seems to be failing at a brew link stage?

[mahdipub]

Ive restarted the macos13 job

It seems to be failing at a brew link stage?

Actually it fails on common when installing pulseaudio via brew: {"ansible_loop_var": "item", "changed": false, "item": "pulseaudio", "msg": "Error: The brew link step did not complete successfully\nError: The brew link step did not complete successfully"}. It occurs when Homebrew is unable to correctly link a package after it is installed. This typically happens if there are conflicts or permissions issues. But it is not related to the changes introduced in this PR as changes are on lines 214 afterwards in role common but this error happened on line 170 (Install Test Tool Packages). I would suggest to run once more and then see what happens?

[sxa]

Ive restarted the macos13 job

It seems to be failing at a brew link stage?

Actually it fails on common when installing pulseaudio via brew:

I've raised a separate issue on this - it's not specific to this PR