So I'm trying to change user502's directory using
usermod -d /home/user502home user502
When I enter than into the shell (I'm on root user) I get "usermod: user502 is currently used by process 4220" and I know the user isn't logged in or anything, I just made the user.
How do I fix this?
You must kill currently used process first. But this process probably is your SSH connection. So, in this case you need to run this commands on nohup.
sudo su
nohup kill 4220; sleep 2; usermod -d /home/user502home user502 &
After you can connect to SSH again.
I got this error when using WSL ubuntu. I fixed it by creating a temp user, setting WSL to launch via that user (ubuntu config --default-user username), logging in as that user, and using usermod there.
An improvement on the top answer: you can use fuser to kill processes which are using your home directory without having to track down the pid.
sudo su
nohup fuser -k /home/USERHERE; sleep 2; usermod -d /home/USERHERE USERHERE &
After some research, this process can be an reoccurring error in Ubuntu and you only need to restart the system and it will go away.
Log in as root, then open terminal and run
kill -9 -u [old_username] && username -l [old_username] [new_username]
After that run
adduser [new_username] sudo
to be able to run sudo commands with the new username.
Related
I need to remotely start bash scripts that perform sudo tasks, such as chmod and ntpdate and echoing to gpio.
A cron job might be the best solution for some of this, but cron is giving me headaches. I'd like to pass on this venue if I can...
I've confirmed that my scripts work locally (I can ssh into the machine and run them without a hiccup.)
However, If I try to run them remotely like so: (this is within a C++ system call)
ssh user#pc 'bash -s' < /home/user/myScript.sh
Commands with sudo fail.
sudo chmod fails with: no tty present and no askpass program specified
echo to gpio fails with: write error: Device or resource busy
sudo ntpdate fails with: no tty present and no askpass program specified
Can anyone help explain, or help me determine whats happening here?
I'm open to band-aids and different approaches, thanks!
You already found the problem yourself:
sudo chmod fails with: no tty present and no askpass program specified
If you run you shell script via ssh and the script wants to run the command sudo, sudo itself will ask for the users password. But the ssh session is not a tty! How should sudo now prompt for a password and how to get your password?
You can do it if you provide the password in the script ( what makes it very dangerous if someone else can read that script! )
script.sh:
echo "your passwd" | sudo -S
As alternative solution you can run the ssh session with a more privileged user.
ssh privileged_user#pc 'bash -s' < /home/user/myScript.sh
All that comes with some danger. Running all commands from the cript with a more privileged user can also be dangerous!
I have the following bash script to restart the network manager in Debian. The script works as is it should, but not as I would like it to. When the script asks for the sudo password I am able to pass it along using echo, but it displays the password in terminal while the script executes, making it less asthetically pleasing than I would like. Is there anyway to have the script enter the password, but not display the password text while the script calls for the sudo password?
I have tried as many suggestions on Stack Overflow as i could find, well as Stack Exchange before submitting this question.
Script is as follows:
#!/bin/bash
clear
echo "Restarting service Network Manager"
echo""
sleep 1
echo -e "\033[0;31m......................................\033[0m"
echo -e "\033[0;31m......................................\033[0m"
sleep 1
echo""
sudo service network-manager restart
sleep 2
echo <Password>
sleep 2
echo "Service Network Manager Restarted"
sleep 1
echo ""
echo "Relinquishing control of terminal to user..."
sleep 7
clear
Remove the echo <Password> line? I am pretty sure it does nothing other than display the password, as sudo apparently (through an appropriate entry in /etc/sudoers) works without you having to give a password. (What you write to terminal with echo does not get passed to any other process.)
Generally speaking, you can use sudo -S to make sudo expect the password on stdin. But also generally speaking, if you have to hardcode a password in a script, you're doing it wrong in some way.
Is there anyway to have the script enter the password
Putting password in script is not a good idea. First, from security point of view, password may be recovered from script from anyone with access to script. Second, from maintenance view, once you change your password, scripts suddenly stop working and you have to update them all.
Fortunately, as you are already using sudo there is better solution. You can configure sudo to allow running certain command without password, by using NOPASSWD rule in /etc/sudoers.
myuser ALL=(ALL) NOPASSWD: service network-manager restart
See:
How do I run specific sudo commands without a password?
How to run a specific program as root without a password prompt?
Warning: Always edit /etc/sudoers with visudo, never directly. It prevents you from breaking /etc/sudoers. Once you break your /etc/sudoers, you won't be able to use sudo, including using sudo to fix /etc/sudoers.
try this /bin/echo -e "password\n" | sudo apt-get update
or see this Use sudo with password as parameter
My application tries to execute roots command "sudo ifup eth0" and "sudo ifdown eth0". But it returned an error "sudo: sorry, you must have a tty to run sudo".
So, it requires a tty to execute the sudo commands. So, I tried to execute the commands by opening tty sessions
gnome-terminal --command="sudo ifdown eth0" &
xterm -e "sudo ifdown eth0" &
then it worked fine. But I am not able to send the command from newly created gnome-terminal or xterm.
i.e., if I close the newly created gnome or xterm windows before they had executed the commands, then the commands were terminated immediately.
Can you give suggestion how to disable the window from closing by the user
or
how to make it invisible to the user?
Note: you can test this by using system-config-network command instead of ifdown and ifup
I would suggest not to use xterm or gnome-terminal to provide a terminal for sudo, but to deal with the "sorry, you must have a tty to run sudo" message directly.
There is a requiretty option in the sudoers file that makes sudo demand a terminal. If this option is unset with !requiretty and the command is executed with the NOPASSWD option sudo should run without the need to open a new terminal window. There are more details in this serverfault post.
That is how sudo is used for instance in cron scripts.
Since requiretty option provides additional security in an environment where sudo is used not only in cron scripts but to let remote users issue commands with elevated privileges, the action of !requiretty can be restricted.
User_Alias LOCAL_USERS = john, mary
Cmnd_Alias NETWORK_SCRIPTS = /sbin/ifup, /sbin/ifdown
Defaults!NETWORK_SCRIPTS !requiretty
LOCAL_USERS ALL = NOPASSWD: NETWORK_SCRIPTS
If you run your code within X session, then you can use gksudo instead of sudo:
gksudo -m "Your message" /command/to/run
It will prompt user for password (if needed) using nice GUI interface. No need to xterm or gnome-terminal.
Effect will be more secure than allowing particular command to run without any password and solution will be more consistent to what users are used to.
In general, sudo or su need to prompt for a password, or programs could escalate their privileges without user intervention. If you application needs to elevate for some purpose, you will need to use an xterm or similar. There are difficulties though in getting the return code back (konsole might need --nofork and gnome-terminal might need --disable-factory, but the options sadly vary by version), and it's not easy to get it right on every system. Most unixes and linux distributions provide xterm, but some old Fedora/RHEL/CentOS provide X without xterm, so it's another dependency to think about.
The command launched by xterm -e sudo -- ... can then do the standard double-fork and setsid. Once the user has entered his password in the xterm, it goes away immediately, but your command runs in the background with elevated privileges. It can connect back to the original program using a socket or fifo to run as a root co-process.
The daemon or disown commands or similar might be useful if you want to wrap an existing application in a double-fork & setsid (eg, xterm -e sudo -- daemon system-config-network or perhaps xterm -e sudo -- bash -c "system-config-network & disown -a").
mongod runs fine as my own system user, but when I attempt to start it from a boot script using sudo, it fails.
I'm not running it as root, i'm doing:
sudo -u normaluser /user/local/bin/mongod --fork --logpath=/var/log/mongodb.log --logappend >/dev/null 2>&1 &
The log file is writeable by normaluser and I have no problem running it as normaluser directly.
How can I start this on boot?
Ok, given our conversation in the comments above I think you should look at the following file:
Red Hat based init script
It seems like you might want to follow that and write something like:
daemon --user normaluser mongod --fork --logpath=/var/log/mongodb.log --logappend >/dev/null 2>&1 &
In Linux how can I enter the password for one of the commands in a chain of commands which requires a sudo. One example which I can think of is when after running a long compile job, I want to shutdown the machine.
make ; sudo init 0
I want the shutdown command to run only after make finishes, but would like to enter the password right away, because I won't be there when the first command is done. Also, I don't want to run "make" with super user privileges. So switching to root and running the commands is also out of the question.
Thanks!
sudo sh -c "su -c 'make' $USER && init 0"
Change your uid early and often. That's the Chicago way!
You can run sudo -v to update the sudo timestamp - this means you won't need to enter a password for x minutes (default is 5). You can change the timeout by editing the timestamp_timeout in the sudoers file.
You also might want to change your command to
make && sudo init 0
which will only shut down if make completes successfully.
One possibility is to use Expect
to automate the password input.
Here's a simple HOW-TO for expect and passwords: http://www.linux.com/archive/feed/56066
Another possibility is to edit your /etc/sudoers and set your user to be able to use sudo without password. if you check the file it will be explained in the comments there.
Why not pipe the password into sudo?
make; echo 'password' | sudo -S init 0
Change the timeout for sudo to something long enough to cover your usage, then run something like sudo echo to authenticate, then run your other commands. As long as the password timeout hasn't been reached, it should execute without asking again.
You can add that to your sudoers file
username ALL = NOPASSWD: /sbin/init
where username is the username you want to allow.