I have some packages from Ubuntu that cannot be installed as root account which is the default on Colab.
I have tried the following:
!sudo useradd -m ted
!passwd ted (set the new password)
!su ted
This generates an error:
sh: 0: can't access tty; job control turned off
I am not a linux person so I am not sure what does that mean.
Don't forget to use ! in google colab.
Add a newuser:
adduser username
usermod -aG sudo username
Switch user:
su username
Installing package:
sudo -S apt install pkg_name
You just can type the command without the sudo part like this !adduser tedand it will work
Then switch to the new user by !su ted then a textbox will appear in it u can write your commands
Related
im using the SSH package in R.
Im trying to switch the user after i have successful opened up a session using the ssh_connect function, the documentation isnt clear to me.
The vignettes reads "Note that the exec functions are non interactive so they cannot prompt for a sudo password. A trick is to use -S which reads the password from stdin:"
command <- 'echo "mypassword!" | sudo -s -S apt-get update -y'
out <- ssh_exec_wait(session, command)
iv tried the following:
ssh_exec_wait(session, c('echo "mypassword!" | sudo -S su - user2'))
but it just outputs the following in the console and doesnt change the user:
"[sudo] password for user1:"
what am i doing wrong here?
When I enter the password for my login it works
But when I use the same password for installing gcc or g++ or any package it asks me "sorry, try again
I have not set any other password other than login
Check if your user is in the sudo group by using this command.
grep -Po '^sudo.+:\K.*$' /etc/group
If your user is not in the root group you'll have to login as root and add your user to the sudo group by typing
usermod -a -G sudo yourusername
-a will append this new group to the rest of the existing groups
-G is used to specify the list of groups to add
I'm trying to setup JupyterHub on an Amazon EC2 instance using these instructions.
In the step titled Run the Hub Server I'm running the server using sudo jupyterhub. But I'm not able to login using the credentials of other Linux users (those apart from the one used to run the server).
It says No such file or directory: 'jupyterhub-singleuser' in the logs and I get a 500 internal server error in the browser. Please help!
Here's how to set up jupyterhub for use with multi-users:
My github here will help you.
Github/Jupyter
Create a group:
$ sudo groupadd <groupname>
Add a user to a group:
$ sudo adduser <username> <groupname>
Using:
c.LocalAuthenticator.group_whitelist = ['<groupname>']
It's been a long time since you asked this, but I think a I can help other users that have similar problems.
I think the problem is that jupyterhub-singleuser is not in PATH for all users. The solution I used was to make symbolic links for the binaries jupyterhub requires.
sudo ln -s /your/jupyterhub/install/location/jupyterhub /usr/bin/jupyterhub
sudo ln -s /your/jupyterhub/install/location/configurable-http-proxy /usr/bin/configurable-http-proxy
sudo ln -s /your/jupyterhub/install/path/node /usr/bin/node
sudo ln -s /your/jupyterhub/install/path/jupyterhub-singleuser /usr/bin/jupyterhub-singleuser
I think it will work
This question already has answers here:
Linux: 'Username' is not in the sudoers file. This incident will be reported [closed]
(11 answers)
Closed 2 years ago.
I am trying to add a particular user in the group using command: sudo usermod -a -G groupname username.
but getting error as "Username is not in the sudoers file. This incident will be reported".
I dont have any idea about sudoers file. Can anybody please help me on this.
The config file /etc/sudoers lists the users who are allowed to run which commands as which user.
On Ubuntu, this file contains a line allowing all users of the sudo group to run commands as the root user.
To check which users are in the sudo group you can type getent group sudo. You can also check the groups of your current user by typing id.
To allow another user to run sudo, you can add them to the sudo group:
sudo adduser username sudo
Or, if your current user can't run sudo, you will need to boot into "Recovery mode" from Grub (hold shift while booting, if your grub menu doesn't show up automatically), or add single to the linux ... initrd ... quiet splash line, then:
mount -o rw,remount /
adduser username sudo
Run adduser for each user you want to be able to sudo. Then exit & resume.
I want to write a shell script to automate a series of commands. The problem is some commands MUST be run as superuser and some commands MUST NOT be run as superuser. What I have done so far is something like this:
#!/bin/bash
command1
sudo command2
command3
sudo command4
The problem is, this means somebody has to wait until command1 finishes before they are prompted for a password, then, if command3 takes long enough, they will then have to wait for command3 to finish. It would be nice if the person could get up and walk away, then come back an hour later and be done. For example, the following script has this problem:
#!/bin/bash
sleep 310
sudo echo "Hi, I'm root"
sleep 310
sudo echo "I'm still root?"
How can I make it so that the user can just enter their password once, at the very start, and then walk away?
Update:
Thanks for the responses. I'm running on Mac OS X Lion and ran Stephen P's script and got different results: (I also added $HOME)
pair#abbey scratch$ ./test2.sh
uid is 501
user is pair
username is
home directory is /Users/pair
pair#abbey scratch$ sudo ./test2.sh
Password:
uid is 0
user is root
username is root
home directory is /Users/pair
File sutest
#!/bin/bash
echo "uid is ${UID}"
echo "user is ${USER}"
echo "username is ${USERNAME}"
run it: `./sutest' gives me
uid is 500
user is stephenp
username is stephenp
but using sudo: sudo ./sutest gives
uid is 0
user is root
username is stephenp
So you retain the original user name in $USERNAME when running as sudo. This leads to a solution similar to what others posted:
#!/bin/bash
sudo -u ${USERNAME} normal_command_1
root_command_1
root_command_2
sudo -u ${USERNAME} normal_command_2
# etc.
Just sudo to invoke your script in the first place, it will prompt for the password once.
I originally wrote this answer on Linux, which does have some differences with OS X
OS X (I'm testing this on Mountain Lion 10.8.3) has an environment variable SUDO_USER when you're running sudo, which can be used in place of USERNAME above, or to be more cross-platform the script could check to see if SUDO_USER is set and use it if so, or use USERNAME if that's set.
Changing the original script for OS X, it becomes...
#!/bin/bash
sudo -u ${SUDO_USER} normal_command_1
root_command_1
root_command_2
sudo -u ${SUDO_USER} normal_command_2
# etc.
A first stab at making it cross-platform could be...
#!/bin/bash
#
# set "THE_USER" to SUDO_USER if that's set,
# else set it to USERNAME if THAT is set,
# else set it to the string "unknown"
# should probably then test to see if it's "unknown"
#
THE_USER=${SUDO_USER:-${USERNAME:-unknown}}
sudo -u ${THE_USER} normal_command_1
root_command_1
root_command_2
sudo -u ${THE_USER} normal_command_2
# etc.
You should run your entire script as superuser. If you want to run some command as non-superuser, use "-u" option of sudo:
#!/bin/bash
sudo -u username command1
command2
sudo -u username command3
command4
When running as root, sudo doesn't ask for a password.
If you use this, check man sudo too:
#!/bin/bash
sudo echo "Hi, I'm root"
sudo -u nobody echo "I'm nobody"
sudo -u 1000 touch /test_user
Well, you have some options.
You could configure sudo to not prompt for a password. This is not recommended, due to the security risks.
You could write an expect script to read the password and supply it to sudo when required, but that's clunky and fragile.
I would recommend designing the script to run as root and drop its privileges whenever they're not needed. Simply have it sudo -u someotheruser command for the commands that don't require root.
(If they have to run specifically as the user invoking the script, then you could have the script save the uid and invoke a second script via sudo with the id as an argument, so it knows who to su to..)