data.coop/ansible
8
3
Fork 7
Code Issues 51 Pull requests 9 Projects 1 Releases Wiki Activity

Use sudo/become instead of root directly #158

Open
samsapti wants to merge 2 commits from use_sudo into main
pull from: use_sudo
merge into: data.coop:main
Conversation 7 Commits 2 Files changed 5 +11 -10
samsapti commented 2023-03-07 11:15:50 +00:00
Owner
Copy link

I have added an extra target create_ansible_cfg in the Makefile to replace the username placeholder, that should be run first thing when cloning the repo.

Supersedes #35.

I have added an extra target `create_ansible_cfg` in the Makefile to replace the username placeholder, that should be run first thing when cloning the repo. Supersedes #35.
samsapti added the
Security Hardening
 label 2023-03-07 11:15:50 +00:00
samsapti added 2 commits 2023-03-07 11:15:51 +00:00
samsapti requested review from valberg 2023-03-07 11:16:06 +00:00
samsapti requested review from reynir 2023-03-07 11:16:07 +00:00
samsapti added 1 commit 2023-03-07 13:37:02 +00:00
samsapti force-pushed use_sudo from eccadb6b3f to bb6e550fea 2023-03-07 13:40:38 +00:00 Compare
samsapti added 1 commit 2023-03-07 13:42:34 +00:00
samsapti added 1 commit 2023-03-07 20:58:00 +00:00
samsapti force-pushed use_sudo from 00334457b2 to 63414b60dd 2023-03-07 21:00:53 +00:00 Compare
samsapti force-pushed use_sudo from 63414b60dd to 0fd11fee37 2023-03-07 21:04:41 +00:00 Compare
reynir commented 2023-03-08 07:15:54 +00:00
Owner
Copy link

I'm not a fan of putting ansible.cfg in .gitignore, and the default remote_user is guaranteed to not work. Can we maybe just remove remote_user? And then either hope that the local username matches the remote username, or have the user set ANSIBLE_REMOTE_USER= environment variable.

I'm not a fan of putting `ansible.cfg` in `.gitignore`, and the default `remote_user` is guaranteed to not work. Can we maybe just remove `remote_user`? And then either hope that the local username matches the remote username, or have the user set `ANSIBLE_REMOTE_USER=` environment variable.
benjaoming commented 2023-03-08 09:40:19 +00:00
Owner
Copy link

I generally like having make targets like create_ansible_cfg in order to bootstrap local configurations in repositories. This is usually the sweet spot between sharing configuration in the repo and needing to individually customize it. But it does have downsides, too.

@reynir

And then either hope that the local username matches the remote username, or have the user set ANSIBLE_REMOTE_USER= environment variable.

That could work, just needs to be written in the README then?

I'm not a fan of putting ansible.cfg in .gitignore, and the default remote_user is guaranteed to not work

I do see the issue here... once a local env is bootstrapped, it's hard to push a change to ansible.cfg through Git, so it has to be communicated manually.

That can probably become an issue... is that what you mean @reynir ?

Can ansible.cfg include configurations from other conf files? Because then we could have one that's actually in the repo.

I generally like having make targets like `create_ansible_cfg` in order to bootstrap local configurations in repositories. This is usually the sweet spot between sharing configuration in the repo and needing to individually customize it. But it does have downsides, too. @reynir > And then either hope that the local username matches the remote username, or have the user set ANSIBLE_REMOTE_USER= environment variable. That could work, just needs to be written in the README then? > I'm not a fan of putting ansible.cfg in .gitignore, and the default remote_user is guaranteed to not work I do see the issue here... once a local env is bootstrapped, it's hard to push a change to ansible.cfg through Git, so it has to be communicated manually. That can probably become an issue... is that what you mean @reynir ? Can ansible.cfg include configurations from other conf files? Because then we could have one that's actually in the repo.
samsapti commented 2023-03-08 12:39:26 +00:00
Author
Owner
Copy link

@reynir @benjaoming we could probably get away with an env var instead. I don't think ansible.cfg can include other files, but we could handle it in deploy.sh using

ansible-playbook --user "${ANSIBLE_REMOTE_USER:-$USER}"

At least for me, my username on hevonen is not the same as my local username.

@reynir @benjaoming we could probably get away with an env var instead. I don't think `ansible.cfg` can include other files, but we could handle it in `deploy.sh` using ``` ansible-playbook --user "${ANSIBLE_REMOTE_USER:-$USER}" ``` At least for me, my username on hevonen is not the same as my local username.
reynir commented 2023-03-08 13:26:54 +00:00
Owner
Copy link

I'm not a fan of putting ansible.cfg in .gitignore, and the default remote_user is guaranteed to not work

I do see the issue here... once a local env is bootstrapped, it's hard to push a change to ansible.cfg through Git, so it has to be communicated manually.

That can probably become an issue... is that what you mean @reynir ?

Yes, indeed. I'm not a fan of putting repository data in .gitignore.

Can ansible.cfg include configurations from other conf files? Because then we could have one that's actually in the repo.

We could use a ansible.cfg.template as a source and have a ansible.cfg target. That would solve the problem of the default REMOTE_USER. Quick update: and allow us to put ansible.cfg in .gitignore.

> > I'm not a fan of putting ansible.cfg in .gitignore, and the default remote_user is guaranteed to not work > > I do see the issue here... once a local env is bootstrapped, it's hard to push a change to ansible.cfg through Git, so it has to be communicated manually. > > That can probably become an issue... is that what you mean @reynir ? Yes, indeed. I'm not a fan of putting repository data in .gitignore. > Can ansible.cfg include configurations from other conf files? Because then we could have one that's actually in the repo. We could use a `ansible.cfg.template` as a source and have a ansible.cfg target. That would solve the problem of the default `REMOTE_USER`. Quick update: and allow us to put ansible.cfg in .gitignore.
samsapti commented 2023-03-08 14:50:51 +00:00
Author
Owner
Copy link

We could use a ansible.cfg.template as a source and have a ansible.cfg target. That would solve the problem of the default REMOTE_USER. Quick update: and allow us to put ansible.cfg in .gitignore.

Isn't that exactly what I've done?

Either way, I actually think it's better to have a .gitignore'd .env file to store a ANSIBLE_REMOTE_USER var, remove remote_user entirely from ansible.cfg, and then handle it in deploy.sh like I described above.

@reynir @benjaoming we could probably get away with an env var instead. I don't think ansible.cfg can include other files, but we could handle it in deploy.sh using

ansible-playbook --user "${ANSIBLE_REMOTE_USER:-$USER}"
> We could use a `ansible.cfg.template` as a source and have a ansible.cfg target. That would solve the problem of the default `REMOTE_USER`. Quick update: and allow us to put ansible.cfg in .gitignore. Isn't that exactly what I've done? Either way, I actually think it's better to have a `.gitignore`'d `.env` file to store a `ANSIBLE_REMOTE_USER` var, remove `remote_user` entirely from `ansible.cfg`, and then handle it in `deploy.sh` like I described above. > @reynir @benjaoming we could probably get away with an env var instead. I don't think `ansible.cfg` can include other files, but we could handle it in `deploy.sh` using > > ``` > ansible-playbook --user "${ANSIBLE_REMOTE_USER:-$USER}" > ```
reynir commented 2023-03-08 16:54:43 +00:00
Owner
Copy link

We could use a ansible.cfg.template as a source and have a ansible.cfg target. That would solve the problem of the default REMOTE_USER. Quick update: and allow us to put ansible.cfg in .gitignore.

Isn't that exactly what I've done?

No, the difference is the template is under a different name and can be checked in to git without a problem.

> > We could use a `ansible.cfg.template` as a source and have a ansible.cfg target. That would solve the problem of the default `REMOTE_USER`. Quick update: and allow us to put ansible.cfg in .gitignore. > > Isn't that exactly what I've done? No, the difference is the template is under a different name and can be checked in to git without a problem.
samsapti commented 2023-03-08 17:41:41 +00:00
Author
Owner
Copy link

Right okay. So what you mean is that we should have an ansible.cfg.template that simply doesn't have the remote_user line, and then a make target that creates ansible.cfg? I guess that'll work, seems like a cleaner way to do it.

Alternatively, the --user flag with a .env could work as well. That would make it unnecessary to run the make target if the local username is the same as the remote username.

What do you think?

Right okay. So what you mean is that we should have an `ansible.cfg.template` that simply doesn't have the `remote_user` line, and then a make target that creates `ansible.cfg`? I guess that'll work, seems like a cleaner way to do it. Alternatively, the `--user` flag with a `.env` could work as well. That would make it unnecessary to run the make target if the local username is the same as the remote username. What do you think?
This pull request has changes conflicting with the target branch.
  • ansible.cfg
  • deploy.sh
View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin use_sudo:use_sudo
git checkout use_sudo

Merge

Merge the changes and update on Forgejo.
git checkout main
git merge --no-ff use_sudo
git checkout main
git merge --ff-only use_sudo
git checkout use_sudo
git rebase main
git checkout main
git merge --no-ff use_sudo
git checkout main
git merge --squash use_sudo
git checkout main
git merge --ff-only use_sudo
git checkout main
git merge use_sudo
git push origin main
Sign in to join this conversation.
Reviewers
No reviewers
valberg
reynir
Labels
Clear labels   
Blocked

Something is blocking progress

  
Existing Service

Issues/improvements regarding existing services

  
Infrastructure Issue

Infrastructure issue that needs investigation or time to fix

  
Refactor

Refactoring of files / file structure or other improvements

  
Security Hardening

Non-verified / non-critical security improvements

  
Security Issue

Urgent security issue that needs to be fixed ASAP

  
Service Idea

Ideas for new services

  
Service Removal

Removal of services for one reason or another

  
Upgrade service
No labels
Blocked
Existing Service
Infrastructure Issue
Refactor
Security Hardening
Security Issue
Service Idea
Service Removal
Upgrade service
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: data.coop/ansible#158
No description provided.
Delete branch "use_sudo"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?