Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unixPB: adds become: true to all kernel config related tasks #3754

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mahdipub
Copy link

@mahdipub mahdipub commented Sep 30, 2024

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.

Signed-off-by: mahdi@ibm.com

Checklist
  • 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

Sorry, something went wrong.

Copy link
Contributor

@karianna karianna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a comment why

@mahdipub
Copy link
Author

Can we add a comment why

Comment updated

@sxa
Copy link
Member

sxa commented Sep 30, 2024

@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
Copy link
Contributor

Haroon-Khel commented Oct 1, 2024

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
Copy link
Author

mahdipub commented Oct 1, 2024

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
Copy link
Member

sxa commented Dec 4, 2024

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
Copy link
Author

mahdipub commented Dec 4, 2024

@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
Copy link
Contributor

karianna commented Dec 5, 2024

Can we add a comment why

Comment updated

Sorry, I meant within the code :-)

@sxa
Copy link
Member

sxa commented Dec 5, 2024

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

@mahdipub
Copy link
Author

mahdipub commented Dec 5, 2024

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.

@mahdipub mahdipub force-pushed the macos_kernel_config branch from d1bd103 to baecaa2 Compare December 5, 2024 15:56
@karianna
Copy link
Contributor

karianna commented Dec 8, 2024

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

@mahdipub
Copy link
Author

mahdipub commented Dec 9, 2024

@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 mahdi@ibm.com is already registered.

@smlambert
Copy link
Contributor

Screenshot 2024-12-09 at 10 50 32 AM

@Haroon-Khel
Copy link
Contributor

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)

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.

Signed-off-by: mahdi@ibm.com
@mahdipub mahdipub force-pushed the macos_kernel_config branch from baecaa2 to 91f1d38 Compare December 9, 2024 16:14
@mahdipub
Copy link
Author

mahdipub commented Dec 9, 2024

Screenshot 2024-12-09 at 10 50 32 AM

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

@karianna
Copy link
Contributor

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

@Haroon-Khel
Copy link
Contributor

Ive restarted the macos13 job

@karianna
Copy link
Contributor

Ive restarted the macos13 job

It seems to be failing at a brew link stage?

@mahdipub
Copy link
Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants