Hi I'm very new to Linux..
Once I have changed ownership of /usr my sudo command failed working ..
Once I changed ownership of /var some other things broke ..
1: I just want to know which are folders where one should never change it's default ownership..
2: what if someone gets permission_denied for /var during installing some packages .. chmod or chown should be used ...
I would never change the ownership in folders unlike /home/* /opt/. Sometimes you have to change the owner if you put your own stuff to /etc/, but you should now what to do.
To install software, even in Ubuntu use the provided tools, 'apt' and 'dpkg' for example. Often the installation needs root rights. Give them with the usage of and additional 'sudo'.
# f.e. installation of a command line browser
sudo apt install w3m
Related
I have installed Bitnami Xampp on linux mint, it is installed inside /opt/
The application is unable to access(Write/Read) files and hence not able to work on it.
Any Solution Please........
Thank You
It is simple access issue. So I need to give read write access to folder and file using chmod command:-
--$ sudo chmod -R 777 opt
I have to admit that I am don't really know Xampp but with the command you mentioned above you changed the the access rights for the top level directory /opt and thru using 777 you gave basically all rights to everbody using your system. If Xampp now tries to write something, it of course can because you gave it the rights (like to anyone else).
The -R option you used in the chmod-command above means, that you have changed the access rights for all subdirectories of /opt also (recursively).
I would recommend that you change this back to the original access rights for /opt and, if you need, just change the access rights for the directory where Xampp is placed. Then Xampp should also work because it can read an write in it's own subdirectory and there won't be any harm for or from other applications from /opt because they can't access /opt/Xampp and Xampp can't access their directories.
After the previous setting
--$ sudo chmod -R 777 opt Xampp is not working with following error
PhpMyAdmin “Wrong permissions on configuration file, should not be world writable!”
Then I followed PhpMyAdmin "Wrong permissions on configuration file, should not be world writable!" and now working fine...
Thank god it saved me from switching back to Windows. That I hate.....
I am developing with Xampp for Linux and Tomcat (similar to Xampp on Windows). Many programs like /IDEA, Tomcat and Xampp are recommended to be installed under /opt Now I have heard that it is not recommended to run services as root, but on Ubuntu (I am using this) unpacking any directory to /opt implies that it belongs to root owner and root group. This may be specific to Xampp as per the instructions on their Linux page:
Step 2: Installation After downloading simply type in the following commands:
Go to a Linux shell and login as the system administrator root:
su
Extract the downloaded archive file to /opt:
tar xvfz xampp-linux-1.8.1.tar.gz -C /opt
Warning: Please use only this command to install XAMPP. DON'T use any Microsoft Windows tools to extract the archive, it won't work.
Warning 2: already installed XAMPP versions get overwritten by this command.
That's all. XAMPP is now installed below the /opt/lampp directory.
* Step 3: Start To start XAMPP simply call this command:
/opt/lampp/lampp start
Placing it here implies that Apache must be run as root as one is only able to run it with sudo on Ubuntu.
This may be an issue specific to Ubuntu. Is it? Because Xampp is a development tool I posted this here as I am more likely to find an appropriate answer here from developers who use it on Ubuntu (and other Linux systems). I would appreciate any information on if the same problem occurs on other systems, I notice my production environment has Tomcat installed in /opt too, but belongs to tomcat: tomcat
The question here is how to get around this for all tools under /opt, because even though Xampp may not be the tool for my needs, I still want to place Tomcat under /opt to replicate my production environment and the same thing will surely happen unless this is just a Ubuntu issue?
Ubuntu and some other distributions differ to the general Linux principle where the account that you create upon install of the OS is added to specific groups that can be viewed with the following command:
groups username
You will notice that root is not amongst these. It is also not possible to log in or su to the root account. sudo is most likey a command that has been granted permission to be used from other accounts so I imagine the 'sudo' command has a file permission of 775 for user: root:root
Thus launching services from /opt' does not run them asroot`
I am trying to run a program from command line in ubuntu and I have a directory that is in the usr/include/ directory that I need to remove so that it will run. How can I do this from command line?
rm -r /usr/include/...
Just use that. But if you need to do that, there is something wrong with your program. If a package installed the directory, use:
sudo apt-get purge package-name
All in all, the directories directly under /usr are under the charge of the package manager, and if you want to do things without that, use the /usr/local dir. Changing other programs resources is a bad idea. Also, don't run anything you don't have to with sudo. That will end badly. And what program would require the removal of a dir in /usr/include?
I have booted my system from a live Ubuntu CD, and I need to fix some package problems. I have mounted my hard drive, and now I want to run apt-get as if I booted normally. ie change the working directory for apt-get so it will work on my hard drive. I have done this before, but I can't remember the syntax. I think it was only some flag, like this:
apt-get --root-directory=/mnt/partition1 install....
But I only get "Command line option...is not understood". Any ideas?
Also this should work:
sudo apt-get -o Dir=/media/partitioni1 update
chroot /mnt/partition1
If your system uses several disk partitions you may have to mount some of them in order to get the package system working (I stopped setting up multiple partitions 10 years ago when hard disks started to get too large for raw physical backup).
This wouldn't work if you don't already have a usable debian system in that location. – akostadinov
If you can't get the package system working when chrooting, perhaps it is too messed up to ever be trusted again - in my experience the effort to bring it back to life rarely pays. If that happens, be happy you can still access your HD, backup your data and perform a clean reinstall.
Some relevant comments from other answer:
apt-get -o RootDir=/tmp/test_apt sets (almost) all paths to be in the different root. btw on a running system, if you copy /etc/apt, /usr/lib/apt, and mkdir -p usr/lib etc var/cache var/lib/dpkg var/lib/apt/lists/partial var/cache/apt/archives/partial and finally touch var/lib/dpkg/status, then apt is going to work in that root. It can even work as a non-root user if you add the option -o Debug::NoLocking=1. The nolock option is necessary because I couldn't find a way to set the lock file inside the different root directory. – akostadinov
Work means using search and downloading packages and such operations. Actually installing is not possible if some essential packages are not already there. debootstrap can help if the goal is actually installing packages in a new root for whatever reason. – akostadinov
Running chroot /mnt/partition1 will start a new shell in which the root of the filesystem is /mnt/partition1. Assuming the apt-get on your hard drive still works correctly, you can proceed from there.
dpkg --root=/mnt/partition1 -i mypackage.deb is an option that doesn't require chroot, but does require you to download the package yourself.
I'm writing an install script in bash for an application on Linux.
This script copies some files into /usr/bin and /usr/share, so it needs to be executed by a root user, furthermore it makes an hidden directory in the $HOME dir for configuration files.
Here is the problem: if a normal user wants to install the program, he needs to be root. But if he is root, the $HOME directory will be /root/ instead of /home/username.
...and, further, if UserA installs the software, but UserB runs it, UserB won't have the hidden directory under /home/UserB. Also, the hidden directory under /home/UserA will be owned by root, not userA.
So, you need to have the application create the hidden directory, not the installer.
Another possible option is not to install in the system directories; one possible alternative location is /usr/local. However, even that can require root privileges. Think about whether it can be installed in other places, and how it could locate its materials.
However, requiring root privileges to install is not the end of the world - a nuisance for some, but not completely out of order. But requiring everyone who uses to have root privileges is way out of order - and if everyone who uses it needs to run the installer, that is bad.
Final point (for now): if you use sudo, it does not change the value of $HOME, even as you acquire root privileges. However, requiring everyone who uses your application to have sudo privileges is not a good thing either.
Must you use $HOME? Maybe you could prompt for the username and install to ~$username instead?