Is it possible to update minion roles on-the-fly via master server call without manual ssh'ing to minion server and changing config files? If the answer is 'yes', how can i do it?
You can define role on minion via module grains.setval (there are also setvals, delval)
salt 'myMinionId' grains.setval roles [db, roleB]
Related
I'm running salt under unprivileged user. The idea is to make some states that can be executed under different unix users, but without giving root privileges to anybody who executes the state. So the question is if it is possible to somehow tell salt to ask for password when switching the user either via runas or when specifying user like in cmd.run. Effectively I would like to achieve something like:
salt '*' cmd.run runas=myuser ask_for_pass=true 'whoami'
test1:
> enter pass for myuser:
'myuser'
or in the same in a form of state:
whoami:
cmd.run:
- user = myuser
- ask_for_pass = true
or one more example that is closer to what i'm actually trying to achieve - installing jboss for a different user (salt-minions and master are running as user "salt"):
$ salt 'host1' state.jboss runas=jboss_user ask_for_pass=true
Salt doesn't do exactly what you're wanting to do here.
Your best bet would probably to use the client_acl or external_auth master config options.
These both will allow you to give either a system user or ldap user the rights to run specific commands.
client_acl docs for authorizing system users: https://docs.saltstack.com/en/latest/ref/clientacl.html
external_auth docs for authenticating external users from PAM or LDAP: https://docs.saltstack.com/en/latest/topics/eauth/index.html
So for example, if you had set up LDAP external_auth, you could require your users to do the following on the command line:
salt -a ldap '*' state.jboss
Salt would then prompt the for a user and password.
I'm deploying virtual guests this way:
salt-run virt.init vmtest 2 2048 salt://images/ubuntu-image.qcow2
It only partially works; vmtest is created and its key is added to the master, but the new minion never connects. So I pull up the vnc interface (which works fine) to see what's going on from the minion end, and...can't log in, because I don't know what credentials to use. Oops.
How do I specify initial login credentials when creating a VM with virt.init?
Well, this may not be exactly what you were looking for, but you can use libguestfs-tools in order to set a password on the image itself.
In salt, you can use cmd.run or pass it in a state to change the password after you install libguestfs-tools like so:
salt 'hypervisor' cmd.run "virt-sysprep --root-password password:'myrootpassword' -a /path/to/image.img"
or
update_pass:
cmd.run:
- name: virt-sysprep --root-password password:'myrootpassword' -a /path/to/image.img
Side note:
If you create or update the image you use to spawn new vms to pre-install salt, and update the /etc/salt/minion conf to set your master, and set it to come up at your desired run level, you should be able to work out a solution where the minion connects on creation.
Good luck, I hope this helps.
I am really curious about when the minion id loads?
http://docs.saltstack.com/en/latest/ref/configuration/minion.html#std:conf_minion-id
Here, it says that the minion id is the system's default hostname.
When does this value get loaded up? Everytime it starts or everytime a change to the system hostname is detected?
What happens if someone comes along and changes the hostname by hand without informing other people which have access to that minion? Does it reload automatically or what?
Here's what documentation has to say regarding ID generation of minion.
I have tried it my self. I was using ubuntu ec2 instance.
The first time you run the minion it uses FQDN to set the id of the instance, so whatever result of hostname --fqdn was there when minion first started that becomes the ID.
Subsequent restart the ID does not change even if you change the
hostname.
If you want to change the ID you need to change it manually in minion
config
file.
You can change current minion id in /etc/salt/minion_id.
When I use a Docker container, I usually add hostname > /etc/salt/minion_id to docker-entrypoint.sh or to the Dockerfile. If you do that, remember to start salt-minion after changing the minion_id (not before).
1)Is there any monitoring or supervision attribute in the OpenLDAP server which can tell if the running OpenLDAP server is a provider or consumer without doing any operations on the Server like ldapmodify?
2) Is their any option to modify the syncrepl config online if yes then how to do ?
The answer to both is to use the 'online configuration' mode whereby the configuration is held inside the directory. Then you can both look up for (1) and modify for (2).
Currently I am running puppet from root user. I want to manage Redis using puppet. I found redis module for puppet. I want to run redis-server using "redis" user. So is it possible in puppet to start command/process/script with different user ?
The best way to accomplish this is to make sure your service management framework is starting the service using the correct user.
If you instead want to use Puppet to start the service directly, which is not best practice, then you can use the user parameter of the exec resource type. The documentation for the exec resource type is located at: http://docs.puppetlabs.com/references/latest/type.html#exec