[salt-users] Dealing with a root_squash NFS mount

[Adam Mendlik]

I need Salt to update a root_squash NFS mount. The NFS server is a NAS
appliance, so I can't put Salt there. I have to update it from the NFS
client machines. Those minions must also make system-level changes, so I
need to run as root. But, when I run the minion as root, I can't touch the
NFS mount.

With Chef, you can pass '--user' to the client and make it execute under
other credentials, which handles this problem pretty well.

Any suggestions on how to deal with this using Salt?

[Colton Myers]

Salt supports running under alternate users:

http://docs.saltstack.com/en/latest/ref/configuration/nonroot.html <http://docs.saltstack.com/en/latest/ref/configuration/nonroot.html>

--
Colton Myers
Platform Engineer, SaltStack
@basepi on Github/Twitter/IRC

I need Salt to update a root_squash NFS mount. The NFS server is a NAS appliance, so I can't put Salt there. I have to update it from the NFS client machines. Those minions must also make system-level changes, so I need to run as root. But, when I run the minion as root, I can't touch the NFS mount.
With Chef, you can pass '--user' to the client and make it execute under other credentials, which handles this problem pretty well.
Any suggestions on how to deal with this using Salt?
--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Adam Mendlik]

Yes, but I need to be able to control the rest of the machine as well.
Running the minion as an unprivileged user will limit me to only updating
the NFS mount. I want to be able to do all the normal salt stuff as root,
and also run certain operations as another user.

By the way, I've looked into running multiple minions under different
accounts, but the existing init scripts don't support it.

[Colton Myers]

Most operations which often require a certain user to run them allow you to pass in a `user` argument.

For example, the `cmd.run` state module function takes a `user` argument:

run_my_command:
cmd.run:
- name: 'echo "some stuff"'
- user: nonrootuser

If there's a specific task you're trying to accomplish as a different user and you don't think it's supported in salt, we should definitely get that fixed.

--
Colton Myers

Yes, but I need to be able to control the rest of the machine as well. Running the minion as an unprivileged user will limit me to only updating the NFS mount. I want to be able to do all the normal salt stuff as root, and also run certain operations as another user.
By the way, I've looked into running multiple minions under different accounts, but the existing init scripts don't support it.
--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Adam Mendlik]

Since we're dealing with an NFS mount, the file module should pretty much
cover it. The ini module would be good to have too.

The file module has a 'user' argument for most functions, but it sets the
file's owner, not the user context in which to access the file. The ini
module doesn't take a user argument at all.

Would it make sense to provide global keywords to specify the user and
group context?

[Colton Myers]

Ah, interesting use case. The idea is that since Salt is usually running as root, we don't need to define an accessing user for file states, because all files are accessible by root. I'm a little surprised root can't touch the NFS mount -- my experience with NFS is limited, but I still feel like root should be able to accomplish any task any other user can.

Implementing an accessing user will be a non-trivial addition. With cmd.run, we just use subprocess to spin up a new process as the specified user. But remote execution modules execute under salt's context, so it may be tricky...

Anyway, I guess the answer for now is you should file a feature request on Github.

--
Colton Myers
Platform Engineer, SaltStack
@basepi on Github/Twitter/IRC

Since we're dealing with an NFS mount, the file module should pretty much cover it. The ini module would be good to have too.
The file module has a 'user' argument for most functions, but it sets the file's owner, not the user context in which to access the file. The ini module doesn't take a user argument at all.
Would it make sense to provide global keywords to specify the user and group context?
--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.