Tag Info

New answers tagged

0

You obviously did not make a lot of research for this From https://mullvad.net/en/setup/openvpn/, you have the following procedure Log in Install network-manager-openvpn (sudo apt-get install network-manager-openvpn) Extract the configuration files Import mullvad_linux.conf using the Network Manager menu


0

The rule should actually be: %www-data ALL = (www-data) NOPASSWD: * The specification in the brackets (Runas in sudoers) is to specify the target user (and/or group) (the one you specify using -u). That said, what you should actually be doing is setting correct permissions, including the setgid bit. How to avoid using sudo when working in /var/www?


2

Adapting one of my previous answers, get the file from the sudo package: apt-get download sudo dpkg-deb --fsys-tarfile sudo_*.deb | pkexec tar -xC / ./etc/ssh/ssh_config Use pkexec instead of sudo when you need root permissions and sudo doesn't work.


4

Don't use setuid shell scripts, the SUID bit is not honored on shell scripts anyway on current systems. Use sudo instead, as you attempted anyway: eka ALL=NOPASSWD: /home/eka/test/test.sh And then: eka$ sudo ~/test/test.sh With that, test.sh will be executed as "root". No need to use setuid here.


3

You have the wrong path to rm, rmdir and mkdir commands. Change your line to this instead: Ruby ALL=NOPASSWD: /usr/bin/apt-get update, /bin/rmdir, /bin/rm, /bin/mkdir


2

When editing the sudoers file you need to use visudo rather than editing the file manually to actually use the resulting configuration immediately. Also, are you sure the username is really "Ruby" with a capital "r"? It's accepted best practice to use all lower case characters in *nix user names.


0

I use the common command sudo usermod -a -G sudo DOMAIN\username and replace DOMAIN\user with DOMAIN\\\username.


0

I've finally found the problem, and it wasn't a server issue. It was a setting in the client, Putty. X11 Forwarding was enabled, and caused all the issues. Switched that off. I noticed that beacuse when connecting from another computer, it wasn't slow. Then I messed a bit with Putty, and bingo.


0

sudo works with a mechanism that is called setuid (Set User ID, or also called suid). If that bit is set on an executable file (like sudo), then the application is executed under the permissions of the user, who is the owner of that file (in case of sudo, the owner is the root user). That means, sudo is executed as root. So far so good. But, now nothing ...


1

It didn't work for me. Instead of GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=off" I used GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=force" and it works. :-)


1

Your text is a bit garbled, but from what I understand, you are looking for a way to use a normal user with sudo. You can achieve it like this: sudo -u $username $command


1

Your question is not making much sense as the user in question has sudo access. So ... Yes a use can change the password on the ssh keys. and A user with root access can change the password of any other user on the system or lock an account without knowing the password of the target account. I am not sure how you are giving them root access or if ...


1

You can manually change the contents of /etc/passwd, /etc/shadow and /etc/group. Or you can use usermod command. Check the manual page for information on how to use them. Then you need to search and change the name in some configuration files under /etc/, I usually uses grep to do that, see manual page about how to use it. Don't forget to check and ...


2

sudo su means run the command su as sudo which means as root. Here the system will ask you for your password since you are a sudoer. So when you offer your password then you are now working with root ability so when you run now su by the time you are using root abilities so you don't need any password. It's same as if you are a root then su to any other ...


2

You are missing sudo in the other side of the pipeline: sudo gzip -dc sda1.image.gz | sudo dd of=/dev/sda1 In a <command> | <command> | [...] command format, each command of the pipeline which requires sudo should be run using sudo, not only the first one. In this case you might not need to use sudo on gzip -dc sda1.image.gz, unless you don't ...


8

This is the intended behavior of vim (and vi). When you edit a readonly file, attempting to write the file the usual way (with :w) fails. This is to prevent you from accidentally changing a readonly file you might not wish to change. If you really want to override the readonly permissions on a file that you own, and write your changes to the file, you must ...


0

If myuser is in the sudo group, then this order of the lines won't provide passwordless access (as noted by Florian Diesch), because the 3rd line overrides the 1st one. myuser ALL=(www-data:www-data) NOPASSWD: ALL # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL So just put the lines into this order: # Allow members of ...


0

Use pkexec instead. pkexec prompts with a list of users who can authorize the action, if the current one can't: user1@ica:~$ DISPLAY= pkexec bash ==== AUTHENTICATING FOR org.freedesktop.policykit.exec === Authentication is needed to run `/bin/bash' as the super user Authenticating as: Muru (muru) Password: I unset DISPLAY to show you the CLI prompt, but ...


1

For individual commands to run as super-user, use: sudo -u your-admin-account sudo COMMAND [ARGS...] (replace your-admin-account with the name of your admin account) To start a shell as your-admin-account use: su - your-admin-account In this shell you can use sudo with your admin account's password. When you don't need the admin shell any more close ...


0

The user that you are trying to install from named user has no sudo power which means he is not an admin on your system. In order to install a package you should be a sudoer which means admin user. So you can fix your problem by either use a sudoer user to install or change your account from normal user to admin user. To change this account to sudo user ...


0

Your filesystem may be out of inodes. Use 'df -i' to check. If IUse% is 100% on root (/) file system, this is the case. This could be because old kernels do not get automatically uninstalled. Refer to How to remove old kernel versions automatically? or Removing old kernel entries in Grub


0

Just do this If you are on Ubuntu naren@kadmin-KCPL190: sudo su Then you will now be a root user and can do anything root@kadmin-KCPL190:# dpkg -i libmotif*i386.deb will work Be careful. If you set a password for root user then it asks you the same for landing to root.Else it will just make you superuser.


0

The error message you displayed is not shown because some process is using sudo. This indicates that you are doing some package management for your system (update, upgrade, install....) So with regard to your demand I'm afraid to say for you that you can't do that in Linux, since the package management always demand the lock to disable other user of ...


1

The /etc/sudoers file controls who can run what commands as what users on what machines and can also control special things such as whether you need a password for particular commands sudo stands for either "substitute user do" or "super user do" (depending upon how you want to look at it). What sudo does is incredibly important and crucial to many Linux ...


1

First check your $PATH variable using the echo command: $ echo $PATH If /usr/local/bin is missing, edit the hidden file .profile, located in your home directory. If this file is missing, edit .bash_profile instead. Add as very last PATH statement the following line: PATH=$PATH:/usr/local/bin


0

You can do this by editing your sudoer file. Open a terminal (ctrl+alt+T) enter the following command sudo visudo Once the file opens enter the following command username ALL=(ALL) NOPASSWD: /path/to/command Replace username with the your own username You can find the path to the command by running which command For more information on editing ...


-1

Yes. Some may recommend marking the script as setUID and owned by root. I would discourage this. Instead, put the user under whose ID the script will run into the sudoers group and configure sudo to allow that user to run the specifically required commands as root without requiring that user to enter a password. This provides audibility and keeps things ...


-1

If it's your computer and if you are only one user, the password should be the same as login password. Otherwise it will be predefined password either from another user or Ubuntu


3

It's just your regular password. The password to run commands with sudo is your password, not a separate password. It is the same password that: you came up with and typed in when you installed Ubuntu or created your account you type in on the login screen (unless you have automatic login) you type in to unlock the screen When you're asked for your ...


0

getent group sudo | grep your-user-name If you find your username among the list from command above then you are a sudo. To use a sudo with no password which is not advised at all and make you in risk to hurt your system Open terminal window and type: sudo visudo In the bottom of the file, type the follow: username ALL=(ALL) NOPASSWD: ALL


0

To make those aliases available for root, you can put them into /root/.bash_aliases. However, if you just need to run those aliases as root from your user, you can just put them into ~/.bash_aliases and add sudo at the start of each alias' command: alias startapache="sudo /usr/local/Cellar/httpd22/2.2.29/bin/apachectl start" alias stopapache="sudo ...


1

The bash shell only reads /etc/profile when invoked as a login shell, which su does not normally do - you would need to invoke su with the -, -l, or --login option. From man su: -, -l, --login Provide an environment similar to what the user would expect had the user logged in directly. When - is used, it must be specified as the ...


1

Try running xhost +localhost in your terminal, and then running the command again. This lets all users on your system (i.e. root) open windows on your screen. Make sure to use +localhost and not simply +, as it's more secure to just allow connections from localhost than from anywhere. To make this permanent, edit the ~/.xinitrc file like this: Run gedit ...



Top 50 recent answers are included