When I try to start chromium I get this:
Please start Chromium as a normal user. If you have previously run Chromium as a root, you will need to change the ownership of your profile directory.
I searched for it, but found articles only like run chromium as a root. I use linux (Ubuntu) not a long time, that I need a help.
Addition If I add new normal user, how can I run chromium from root like them?
You can run Chromium with an argument from the command line like this
chromium --user-data-dir=/foo/bar
This will enable you to run it as root. This is not advised though for security reasons.
If by running as a normal user you mean execute the command as someone else, you can just do
su - username -c "chromium --user-data-dir=/foo/bar"
if you need to use the user's settings, then the path(user-data-dir) should point to them.
If username and password is already set in your Linux System then, answer by #Dropout is perfect.
If there is no password set and you want to run as a normal user, you can just do
su -c "chromium --user-data-dir=/foo/bar"
This will allow you to open Chromium when you don't have a password defined in your Linux System
Related
I'm building an electron-app where i need to run commands with superuser privileges, i don't want to ask the user for a password every time. How can i start the app, asking only for the password once. I tried:
sudo /path/to/electron --no-sandbox main.js
Unfortunately, i get this error:
I know there are libraries like https://www.npmjs.com/package/sudo-prompt, but i only want to ask once for permission. I run everything locally, so please don't tell me about the security risk of running browser as root.
I'm using the AI Platform notebook and I want to install cuda because the Tensorflow can't use GPU.
sudo apt-get install cuda-cudart-10-0
Then in the command line it's asking me for password.
(base) jupyter#cuda-10-1-20201008-115420:~/tutorials/stylegan2$ sudo apt-get install cuda-cudart-10-0
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for jupyter:
Sorry, try again.
I don't recall I gave it any password while setting it up. Is there a default password for it?
To answer the first question, our Notebooks provide TensorFlow and when you create it, you can select to install Nvidia Driver automatically. Probably this option was missed during instance creation.
With respect to the second question, from the output, seems to be that you are in Jupyter Terminal.
Jupyter Notebooks provides access to Instance OS which could be Debian 9/10 or we support Ubuntu now. Jupyter Terminal process is running as jupyter user. While you can still run process as root. I would suggest you that you login via SSH and run commands directly from there. If you create the Notebook via UI we now provide OS login feature which allows you to access instance via SSH with IAM permissions hence your Google Cloud user account. If you are not sure of any of this, please contact your IT admin.
What do you think sudo does? If this is your first time using a Linux system, know that prepending every command in Linux with sudo is same as typing cmd in the windows run box and then pressing shift+enter. sudo is a way to tell the OS that I need admin rights (or in Linux's case, root permissions). So, it is bound to ask you for the password.
The password it is asking for is your account password. Also, it is usually a good idea to set up the root password when in first use. To set it up, drop into the root prompt from your user account using sudo su. Then type in passwd to set up a new password for the root user. Log out, and restart the machine.
Do not forget that root account has the ultimate privileges, and unless absolutely necessary, it is always better to prepend the command with sudo instead of dropping into the root prompt.
PS: A hint: sudo <command> followed by the caller's password is same as su -c '<command>' followed by the root account's password
You also might want to take a look at fakeroot
Which linux distro are you on? Like Kali has default password as root or toor or kali depending on version
I recently noticed a fairly strange and for me unexpected behaviour in Xubuntu 12.04 and 14.04.
I was doing the following:
Testing if my user in in the group users, with
groups $USER
This is not the case by default. So I add my user to this group:
sudo usermod -a -G users $USER
I the can check the file /etc/group and will see my user added in the entry.
I then would like to give the group users access to some files, in my example the www and cgi-bin directory:
sudo chgrp users /var/www /usr/lib/cgi-bin
I also want that my group can write into the directories:
sudo chmod g+w /var/www /usr/lib/cgi-bin
I would assume, that I can now create a file in those directories, but I can't. Neither by commandline, nor by the standard filebrowser from Xubuntu.
Somewhere I read, that I need to logout from the terminal to make it work, so I close and reopen the commandline terminal, but it is still now working.
But: It I reboot the whole system everything works as it should...
Seriously??? Why is this, is it a bug or a feature and are there better ways then restarting the complete OS?
(I thought the strength of Linux is exactly that you don't need to reboot all the time like in other "popular" OS)
(Note: I have not tested this on other systems as e.g. Debian yet...)
Group memberships are inherited from process to process like many other things in a unixoid environment. That means a running shell will not be affected from such changes in the account configuration. Also just opening a new terminal or shell will not show the change, since it is spawned from an already running process, ultimately from the initial process started right after the login.
You have to re-run the login process instead. Either by restarting the graphical environment, or by doing a logout/login sequence when working on the virtual terminals. Also obviously rebooting will lead to a new login process.
The only direct alternative is to spawn a new login shell explicitly: bash -l for example does the trick: it re-executes all stuff run through at login time. But note that this only effects that started shell and processes spawned from it. It does not affect other already running processes. So you have a somewhat mixed environment then...
I've got an SVN instance installed on a free EC2 AWS server. In short: I'm using LAMP.
Using what I read in this article and encountered the "you need a TTY" error as mentioned in the comments. I followed the second resource and it cleared the error message, but doesn't seem to be executing the script. When I manually run the script, however, it works.
Any clue what I'm missing?
When I followed the second resource to fix the TTY error I changed the contents of my /svn/repository/hooks/post-commit script from:
#!/bin/bash
sudo /usr/local/bin/svn-post-commit-update-mysite 1>&2
to:
#!/bin/bash
su –session-command=”/usr/local/bin/svn-post-commit-update-mysite 1>&2″ dynamic &
First possible issue:
You cannot rely on the value of the $PATH variable inside the hook. This means you need to specify complete paths for all executables.
In particular, "su" is a program located in "/bin/sh" in most distributions. To be sure, type
type su
Next possible issue:
Is your subversion server being run as root? su will try to ask for password if run by other users, and will fail if it's not being run interactively - even if the user is in the sudoers file!
If you are using Apache+DAV, this means the apache service must be run as root for this to work (instead of www-data), which is a serious security problem.
You probably don't need to use su or sudo at all if all of the files are owned by the same user (www-data, for instance). You can change the ownership of the site files with something like
sudo chown -R www-data:www-data /var/www/<my-project>
And then remove the sudo and su from both the hook and the svn-post-commit-update-mysite file.
My best guess would be that something in your script depends on the PATH environment variable. Subversion runs hooks in an empty environment for security reasons. So you need to either setup the environment in your shell script or use absolute paths.
You might want to read the Subversion book entry on implementing hook scripts. The particular issue I mentioned is explained in the information block.
I want to run a script on remote server using SSH.
I have write all the code which runs properly using system command.
To run my code on remote server I need some packages which I need to install on remote server.
To do so I need login into remote terminal as a ROOT user. When I try to do using Ruby script so I get something like following
[not_root_user#remote_server]$ su
Password:
I need some command using which I can able to login into the remote server something like following
[not_root_user#remote_server]$ su -p ******
[root#remote_server]#
Is there any linux command which accepts the password in it?
So you want your script to act as root?
It's not really recommended, but you can use expect: http://en.wikipedia.org/wiki/Expect
The wiki there has a walkthrough for a basic automated telnet session that you could adapt to your needs.
However, you're going to have your root password in plain text, which could be a security issue. If you go that route, I'd definitely obliterate all copies of that script from the universe once this package is installed.
But if you're allowing direct root logins, you've already got a bit of a security problem. Sudo works out-of-the-box on every modern linux distro I've used, I'd stick with that, if possible.
Another option which is equally tasteless would be to set up root-to-root login without a password via ssh.
Sudo would be my first option to getting around this. Although not the best option.
You can also use Key authentication with SSH, and if password authentication is turned off there is no need to enter a password.