is there any way to switch the user (to root or so) while deploying with capistrano without closing the current session (session is started with ssh keys)?
So i want to start the deployment with user foo and then change to root and then execute some commands.
Thanks for your answers!
You can use the capistrano sudo helper:
task :some_task_as_root do
run "#{sudo} some_command"
end
you can even specify a different user:
task :some_task_as_other_user do
run "#{sudo :as => 'other_user'} some_command"
end
The sudo helper will take care of getting the password from you if necessary and pass it along correctly.
You don't say where you want to run the commands as root. On the local system? On the remote system?
Each "run" sort of command in capistrano uses a separate new ssh connection. As stated above, "sudo" is the official way to run one set of statements as root.
If you're comfortable giving Root an ssh key to be able to log in directly via ssh, you can specify a user to ssh over as. I wouldn't recommend it, though.
In a Solaris environment without "sudo" (sigh), we use pfexec instead.
I believe sudo is what you need
your user should be sudoers groups before.
then use it:
task :specific_sudo_take do
run 'sudo -c sh "whoami' #put your sudo command here
end
Related
I have a post-commit hook in my subversion that will export a copy of my repo to a desired location for deployment. That part works fine, but it comes in with apache:apache. I need this to be changed to prod_user:prod_user. If I try to add a chown statement in my script, it will fail. If I try to use sudo, it will ask for a password that I cant give because this happening in a post-commit script. I'd like this to be as automated as possible.
My question is: How can I make this work? I need to export the contents of my repo to the production folder and convert the users/groups to match existing production users/groups.
Is there a way to pass my password as an argument to a sudo command?
Thank you for your help!
Is there a way to pass my password as an argument to a sudo command?
Don't do it, if at all possible. This will leak your password to anyone that can read the script.
But if you can't avoid it, use echo <password> | sudo -S <command> - -S makes sudo read from stdin so you can give it the password from there
Don't do any of sudo, chown, chgrp. It is not the responsibility of the uploader to fix permissions on the remote server.
Have the server administrator properly setup these, so that pushing production files from the repository works straight without messing with sudo permission at the server.
If you are the one same person, then take the time to fix the server side to avoid having a remote user elevate its privileges (even temporarily with sudo) for the sake of fixing uploaded files permissions.
Use crontab -e as root user, then you can change ownership without escalation of privileges.
Or run as prod_user and make it check out the code ...then it is already the owner of the files.
Keeping a file with the last deployment timestamp can be used to compare to HEAD timestamp.
I have the following task for my golang code:
The command has to be run as root user on the server remotely in bash and the command output has to be fetched in a variable.
Logging over ssh as root is disabled.
sudo on the server is disabled, so I have to use 'su -' and type password
since I want to make it as automated as possible in bash, the password has to be stored inside the command
Here are the workflow actions:
Login via SSH (as unprivileged user) to remote host
Elevate to privileged 'root' user --> su -
Type the root password
run the command which root can execute
get to output to string on localhost and do some actions
I have Googled for days, but it seems that I cannot find a solution for this.
Does anyone have a solution to this?
The issue you are facing is concerning interacting with the command after it has been executing.
It is quite easy to use exec.Command for non-interactive commands.
I would recommend using Expect for interaction, or the Golang equivalent located here.
I need to call postfix reload from a script accessible from php webpage. postfix reload requires superuser privileges. I can do it using echo "password" | sudo ... But I don't want to give superuser privileges to a script accesible from an apache, nor to write the password there in a plaintext. How do you call such command without creating security problem? How can software like the ISPConfig solve this need?
The user under which Apache is running (ex. apache) must be allowed to execute "sudo postfix reload" without a password. To do that you need to add the
following line in the '/etc/sudoers' file:
apache ALL = NOPASSWD: /path/to/postfix reload
I recommend in the script to use 'sudo /path/to/postfix reload' since the postfix file might not be in the default path of apache user.
Regarding security, you need to make sure that this command will not be launched to often since it might cause performance issues.
Since the command has specified an argument the even if your site would be compromised, the postfix reload will only perform a specific action without possibility to alter that behavior (as long sudo and postfix are up2date).
I want to run the following sample bash script which needs sudo password for a command
#!/bin/bash
kinit #needs sudo password
vi hello.txt
while running the above script it is asking for password.
How can i pass the username and password in the command itself or is there any better way i can skip passing my password in the script ?
TL;DR
You can't—at least, not the way you think.
Longer Answer with Alternatives
You have a couple of options:
Authenticate interactively with sudo before running your script, e.g. sudo -v. The credentials will be temporarily cached, giving you time to run your script.
Add a specific command such as /usr/lib/klibc/bin/kinit to your sudoers file with the NOPASSWD option. See sudoers(5) and and visudo(8) for syntax.
Use gksudo(1) or kdesu(1) with the appropriate keyring to cache your credentials if you're using a desktop environment.
One or more of these will definitely get you where you want to go—just not the way you wanted to get there.
So if you have access to your full system, you can change your sudoers file to allow certain sudo commands to be run w/o a password.
On the command line run visudo
Find your user and change the line to look something like this:
pi ALL=(ALL) NOPASSWD: /path/to/kinit, /path/to/another/command
That should do it. Give it another shot!
Hope that helps
You shouldn't pass username and password. This is not secure and it is not going to work if the password is changed.
You can use this:
gksudo kinit # This is going to open a dialog asking for the password.
#sudo kinit # or this if you want to type your password in the terminal
vi hello.txt
Or you can run your script under root. But note that vi is going to be ran as root as well, which means that it will probably create files that belong to root, that might be not what you want.
I am trying to automate my server provisioning process using chef. Since I don't want to run chef as root, I need a chef/deployer user. But I don't want to create this user manually. Instead, I want to automate this step. So I took a shot at scripting it but ran into an issue:
The problem is that if I run
>ssh root#123.345.345.567 '/bin/bash -e' < ./add_user.sh
where add_user contains
//..if the username doesnt exist already
adduser $USERNAME --gecos ''
I never see the output or the prompts of the command.
Is there a way to run interactive commands in this way?
Is there a better way to add users in an automated fashion?
Try this:
ssh -t root#<ipaddress> adduser $USERNAME --gecos
Not sure why you have a $ in the IP address in your original example - that's likely to cause ssh to fail to connect, but since you didn't indicate that sort of failure, I'm assuming that's just a typo.
Since add_user.sh is just a simple command, there's no need for the added complexity of explicitly running bash or the redirection, just run the adduser command via ssh.
And lastly, since $USERNAME is likely defined on the local end, and not on the remote end, even if you could get your original command to "do what you said", you'd end up running adduser --gecos on the remote end, which isn't what you intended.
Try using :
ssh -t root#$123.345.345.567 '/bin/bash -e' < ./add_user.sh
instead.