I have to run emacs in sudo mode, to edit some .html or .php files in my /var/www directory.
When I run it in normal-user mode, there's no problem with the syntax, and the colors (I installed the php-mode.el extension). Unfortunately when I run it in sudo mode, I lose this configuration.
Is there any way to get it back?
Unfortunately when I run it in sudo mode, I loose this configuration, which is sad.
That's completely expected. When you run a command with sudo you're running it as a different user, usually root. In most cases the target user's configuration will be used.
Is there any way to get it back ?
I believe the best option here is to run Emacs normally and then edit the file as root using TRAMP. In this case I think prefixing the file with /sudo:: will do the trick, e.g. C-x C-f /sudo::/var/www/html/foo.php RET. Emacs will prompt you for your password, just like sudo would on the command line.
TRAMP does a lot more than letting you edit certain files as root via sudo, and it is probably worth your time to browse its manual.
It is unlikely that you would ever need to run sudo emacs, and it's bad practice to run things as root unnecessarily.
The sudoedit command / sudo -e option exists for the purpose of editing files owned by other users. The editor which will be used is described in the manual (man sudo) under the description for the -e option:
The editor specified by the policy is run to edit the temporary files. The sudoers policy uses the SUDO_EDITOR, VISUAL and EDITOR environment variables (in that order). If none of SUDO_EDITOR, VISUAL or EDITOR are set, the first program listed in the editor sudoers(5) option is used.
With this approach, you will be editing a file as your normal user, and hence with your normal editor config.
Alternatively, use the Tramp methods built into Emacs, as per Chris' answer (which is most likely simpler if you are editing many files).
If these are files you essentially need to have write access to in general, perhaps you should allocate yourself to a group with write access.
Related
I'm having:
Ubuntu Linux 12.04 LTS
Apache Web Server(Apache httpd 2.4.16)
PHP 5.5.29
Now, whenever something goes wrong in code I always see a white screen in my browser window with no output at all. So, I googled for the solution and come to know that I have to turn the error reporting on in order to get the detailed errors/exceptions/warnings/etc.
And for this I come to know that I need to change php.ini file which Apache web server is making use of.
I opened up the file '/etc/php5/apache2/php.ini' by selecting it with my mouse, right click on the file '/etc/php5/apache2/php.ini', selected the option 'Open With Sublime Text2' and open up the file in Sublime Text Editor.
I did one small change on line no.466 of '/etc/php5/apache2/php.ini' file as follows :
display_errors = Off //Old code present on line no.466 of php.ini
display_errors = On //New code changed by me on line no.466 of php.ini
I am not sure is this the only change I need to make to '/etc/php5/apache2/php.ini' file to get errors/warnings/exceptions/etc. Please guide me in detail regarding the changes I need to make to the file '/etc/php5/apache2/php.ini' to get all the possible errors/warnings/exceptions/etc.
Now when I tried to save this file I got a pop-up saying 'Unable to save /etc/php5/apache2/php.ini'.
I'm the owner of my laptop, the system is mine, I am the administrator of my system and still I can't make any change to the file. This is really an un-understandable, useless and strange stuff for me. Previously when I was using PHP on my windows machine such weird things and headache never happened.
Please someone take me out of this bloody mess by giving descriptive and step by step answer.
Few people are saying I have to open up the terminal and type commands there. But I'm not getting What is terminal? Where it is? How to open it? What is root user and what is sudo user? What does each of the users do? What's the difference in between them? The purpose of graphical text editor is to manipulate files and this Ubuntu is preventing me from doing it.
Everything is strange here with Ubuntu Linux. What's the use of it? etc.
What is terminal?
Terminal is an interface where you execute your commands. More details here. Its like cmd in windows.
Where it is? How to open it?
Open the Dash (Dash is similar to the Start button in windows)
and type terminal.
The black board like icon with >_ is your terminal, click on it.
This is what a terminal looks like.
What is root user and what is sudo user? What does each of the users
do? What's the difference in between them?
Quoted from Ubuntu docs
In Linux (and Unix in general), there is a SuperUser named root. The Windows equivalent of root is the Administrators group. The SuperUser can do anything and everything, and thus doing daily work as the SuperUser can be dangerous. You could type a command incorrectly and destroy the system. Ideally, you run as a user that has only the privileges needed for the task at hand. In some cases, this is necessarily root, but most of the time it is a regular user.
By default, the root account password is locked in Ubuntu. This means that you cannot login as root directly or use the su command to become the root user. However, since the root account physically exists it is still possible to run programs with root-level privileges. This is where sudo comes in - it allows authorized users to run certain programs as root without having to know the root password.
Editing the php.ini file:
Now that you know what terminal is, open the terminal and type:
sudo vi /etc/php5/apache2/php.ini
Note: There are various other editors, like nano, gedit etc.
You'll be prompted to enter the password:
[sudo] password for user:
Just type in the password and hit enter. You'll see the contents of php.ini in the terminal. Now, scroll and search for the line Display_errors =off. You will have to change this to Display_errors =on, to do this change press i, make your changes, press esc, press shift+q type wq! and hit enter.
Now, you will have to restart apache to have the changes take effect. So, type:
sudo service apache2 restart
and hit enter. Thats it. Hope that gives you an idea :)
Regarding php.ini
You can do runtime change in all settings of your php.ini or by editing php.ini.
You should keep error_reporting false by default. And in development you can make reporting on runtime.
error_reporting(E_ALL);
ini_set("display_errors", 1);
Do this only if you are in development mode to see all fatal/parse errors or set error_log to your desired file to log errors instead of display_errors in production (this requires log_errors to be turned on).
Regarding file changes
php.ini needs to be edited by root user.
So you can edit by terminal:
Open terminal
Switch user as root
Edit php.ini by vi editor and do changes.
Restart apache server
Or If you still want to edit by sublime
Open php.ini by sublime with root access
You need do required changes in php.ini
Restart apache server
Terminal
The terminal is an interface in which you can type and execute text based commands.
Think of it like cmd in windows.
How to run it:
Open the Dash (Super/window Key) or Applications and type terminal, or use the keyboard shortcut by pressing Ctrl+Alt+T.
As this is to broad, and you actualy don't need terminal for your problem; for a great explanation of terminal please see: What is a terminal and how do I open and use it?.
Display error settings in php.ini
There are 2 settings you must edit:
error_reporting = E_ALL
Make sure it only have the value E_ALL.
E_ALL = Show all errors, warnings and notices including coding standards.
E_NOTICE = Show notices
E_STRICT = Show coding standard warnings
if you put ~ in-front it, it means Except.
display_errors = On
Unix-like OS file permissions
In unix-like OSes, files and directories are owned by a user and distinct permissions (read, write, run) apply to the owner.
These are very simplified explanation:
The '/etc/php5/apache2/php.ini' file is owned by root and with write permission only for root, so you can't edit it unless you are the user root itself.
But there is a way for you to edit files owned by another user, and that is with a command: sudo (superuser do ...), or gksu/gksudo for graphical interfaces software.
You may think that your username is another administrator/SuperUser, so why can't you just edit and save the file? Well, in actual you are not. Your user is just a regular user, but with permission to do SuperUser task. In other word you are just a sudo user (sudoers).
So the only way for you to save the changes you made, is to run Sublime Text using root privilege.
This can be achieved from the terminal by executing it via command: sudo sublime or gksu sublime.
Or without terminal:
via Dash (press super/window key), just type gksu sublime and press enter (you will be asked for your password).
This makes you run sublime text editor as root user, so now you can open the '/etc/php5/apache2/php.ini' file and edit it and save it.
(If you don't have gksu, install it via Ubuntu Software Installer.)
I use gksudo and gedit to do the job.
gksudo makes it possible to open a graphical interface. Gedit is the default text editor for GNOME. If you have KDE, then will you use kedit.
First I find the correct location of the used configuration file. You can find it easily making a php file calling the function php_info.
The content of the php file is a call to one function:
phpinfo();
That is it. I always have a file info.php in the documentroot of apache (in Ubuntu /var/www. Then I make a call to that file with:
http://localhost/info.php
and a document containing a lot of information will be returned. In it, you have a configuration value:
Loaded Configuration File
The value on that line is the php file that is used by the apache server. You should edit that file in order to see errors displayed. Lets call that value %phpini-file%.
Next I open a terminal
(see https://help.ubuntu.com/community/UsingTheTerminal)
and type
gksudo gedit %phpini-file%
and I do traverse the file until I see error handling and logging.
After that you will find the variables that you would like to be changed.
On a development machine I set the variable error_reporting to:
error_reporting = E_ALL
The documentation in the file gives you good suggestions.
Underneath that variable you have the variables display_errors, display_startup_errors and log_errors. I always give those variables the values On on my development machine.
Some lines below that you have the variable track_errors. I put it to On.
After making those changes will you have to restart apache.
The way I do it is:
sudo /etc/init.d/apache2 restart
It is equivalent to
sudo service apache2 restart
but it is how I have remembered it.
Instead of a terminal you can type ALT + F2 and you will see a command line appear in the midst of your screen. Next you type your command and the action will be performed.
Root is the user that has all privileges on an unix based system. Sudo is an abbreviation of super user do and makes it possible to execute commands as if someone is root. The whole root concept makes it safe that not any user can do anything on the system. You must be root or otherwise get sudo privileges in order to make changes on the system.
You just need to press
Ctrl + Alt + T
and you'll see a window appearing, which is nothing but the Terminal.
There you just need to type :
sudo gedit /etc/php5/apache2/php.ini
[Gedit is nothing but the default linuk editor]
After that you'll be asked to enter the password, where you need to enter your system's password.
The file will open in the editor, just find Display_Errors in that page and replace off with on, so it will be :
Display_Errors=on
After the changes save and close that file.
And just restart your apache by typing this command on the TERMINAL again :
sudo /etc/init.d/apache2 restart
I'm using Laravel, and whenever the logs or the cache is being written to the storage folder, it's giving 755 permissions, and creating the owner as daemon. I have run sudo chown -R username:username app/storage and sudo chmod -R 775 app/storage numerous times. I have even added username to the group daemon and daemon to the group username.
But, it still writes files as daemon, and with 755 permissions, meaning that username can't write to it.
What am I doing wrong?
This one has also been bugging me for a while but I was too busy to hunt down a solution. Your question got me motivated to fix it. I found the answer on Stack Overflow.
In short, the solution is to change the umask of the Apache process. The link above mentions two possible places to make the change: you add umask 002 to
/etc/init.d/apache2
/etc/apache2/envvars (Debian/Ubuntu) or /etc/sysconfig/httpd (CentOS/Red Hat), or
Edit
I recently upgraded from Ubuntu 12.04 32-bit to 14.04 64-bit and, to my great irritation, I could not get this to work. It worked for some PHP scripts but not others - specifically, a short test script I wrote worked fine, but the Laravel caching code did not. A co-worker put me on to another solution: bindfs.
By mounting my project directory (/var/www/project) in my home directory (~/project) with the appropriate user mapping, all my problems were solved. Here's my fstab entry:
/var/www/project /home/username/project fuse.bindfs map=www-data/username:#www-data/#usergroup
Now I work in ~/project - everything looks like it's owned by username:usergroup and all filesystem changes work as if I own the files. But if I ls -la /var/www/project/, everything is actually owned by www-data:www-data.
Perhaps this is an overly-complicated solution, but if you have trouble getting the umask solution to work, this is another approach.
In this instance Apache isn't doing anything wrong. Apache reads and writes files based on the User and Group settings in its configuration file. The configuration file in question is like /etc/httpd/conf/httpd.conf but the location and even name differs depending on the system you're using.
It's also worth noting, that if you're running PHP as something such as FastCGI, then it'll use the user that FastCGI is set to use, seeing as that is the bit that modifies and creates files, not Apache.
I have a PHP script that compiles LaTeX documents with the use of:
exec('cd /path/to/doc && /usr/bin/latexmk -pdf filename.tex');
This is working for some of my LaTeX documents but my latest document doesn't compile and a look at the log reveals:
!pdfTeX error: pdflatex (file ecrm1000): Font ecrm1000 at 600 not found
==> Fatal error occurred, no output PDF file produced!
Which I have found is the result of LaTeX not being able to see the required font packages. When I run the same compile command under my username the document compiles as it should. So my question is, how can I get PHP (executing as www-data) to get access to the necessary LaTeX packages?
I have tried installing the required package under the www-data account using:
sudo -u www-data sudo apt-get install texlive-fonts-recommended
but it askes for www-data's password, which I don't believe was set by me and isn't anything I've thrown at it.
I'm running Ubuntu 12.04 if it's any help.
sudo mktexpk --destdir /usr/share/texmf-texlive/fonts/pk/ljfour/jknappen/ec/ --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 ecrm1000
... makes the font available for all users (same as in missingfont.log but with --destdir argument).
I run with similar problem and it was solved by setting $HOME environment variable to /var/www in a shell-script which invoked pdflatex (or I believe any folder writeable to www-data is ok here). See the details on TeX.SX.
You are right with the sudo idea, but to get around the password problem, there is a simple solution.
www-data must be in the sudoers list, at etc/sudoers, and within this list you can define how the super commands are controlled. It is possible to set www-data as a sudoer that doesn't require a password... but that's not a very clever idea in terms of security. Therefore, in the sudoers list, you can specify what commands are allowed to be executed by the user. Allowing only the /usr/bin/latexmk command will get around security problems, and allow your webserver to run super commands without a password.
Check out this help page for Ubuntu: https://help.ubuntu.com/community/Sudoers - most notably the NOPASSWD section.
The example in your case would be:
# This lets "www-data" user run a command without a password
www-data mark-computer= NOPASSWD: /usr/bin/latexmk
Here's what eventually got the compilation working.
Under my own home folder was a hidden folder that LaTeX was using to store the fonts it needed ~/.texmf-var. This folder contained fonts/pk/ljfour/jknappen/ec and in there were 13 font files (some of which were the ones that latexmk was complaining about).
The solution was to have PHP generate the LaTeX file I wanted to compile (file.tex) into a temp directory (where I had copied the fonts) where they would be compiled and then moved to where I wanted to store the output PDFs. I'll explain with an example:
file_put_contents('~/website/latexFiles/temp/file.tex', $latex_data);
exec('/usr/bin/latexmk -pdf -cd ~/website/latexFiles/temp/file.tex');
exec('mv ~/website/latexFiles/temp/file.pdf ~/website/pdfs/desiredFilename.pdf');
exec('rm ~/website/latexFiles/temp/file.*');
So the first line generates the latex file in the directory where I'm going to compile to PDF (where $latex_data is a string containing the LaTeX document I want to create).
Now, the part that makes this all work is creating a directory in ~/website/latexFiles/temp called $HOME. Then copying (or maybe linking, but I copied) ~/.texmf-var into ~/website/latexFiles/temp/$HOME. This is the path that latexmk will look into for the fonts it needs. Use the -cd switch so that latexmk moves into ~/website/latexFiles/temp before trying to compile the LaTeX file, where it will then be able to fine the fonts.
The third line copies the .pdf file out to where I eventually wanted the output file and the last line removes all the remaining files from the temp directory with the same filename. I make sure I use unique filenames for the .tex files so I'm not removing files that another user may be generating.
Hopefully someone else finds this useful.
Update: turns out the problem is more complicated than I originally thought. I was simultaneously trying to troubleshoot why my mkdir stopped working and it was because I had manually changed permissions of the parent directory to test then switched them back and added a chmod to the script which doesn't work since that one is being run by apache and not myself. I'll be posting a new question with the larger problem as I think adding all of this into this one will become confusing.
I'm a lab instructor at my university and I've been rewriting the script they provide for uploading assignments because the one they have is old and buggy. Instead of modifying the existing script (written in python) I've been writing it from scratch in php.
I've come across an issue where it seems that chown is not working. The php scripts run under the user apache. I'm not sure if that user is 'priveleged' or not but the original script used chown.
Can I assume that therefore apache should have the needed authority and that my issue lies elsewhere or is that faulty logic?
The server is the university's and there is no way they will let me make any configuration changes. I do believe that it is CentOS that they're running. There is no error message i just noticed that I can chmod the file and change the permissions but that the chown command on the next line seems to have no effect.
ls -al on the old scripts show:
-rwxr-xr-x 1 mattw labstaff 5067 Sep 1 17:52 File_Upload.cgi
Doesn't look like the setuid bit is on.
Stefan mentioned "The user apache most likely doesn't have enough permissions to chown a file/folder it does not own". The directory I'm attempting to chown was just created with a mkdir so it should be owned by apache. Should chown work regardless of privilege when you already own the file?
Apache probably doesn't have the privileges to do so. It depends on which environment it's running in. You said apache is running under the user apache, so I'm just going to assume that it's RHEL or a RHEL variant such as Centos.
You would be able to edit the sudoers file (with visudo) and give apache the ability to sudo without a password under a certain directory. Be aware that this isn't recommended if you're very security conscious.
Adding something like
apache ALL = NOPASSWD: /bin/chown 1[1-9][0-9][0-9]\:1[1-9][0-9][0-9] /var/www/[a-zA-Z0-9]*
You may be able to add apache to a different group, or another user to the apache group or something of the sort and chmodding it to 0775 or 0664 instead.
It would be best to post the code that's throwing the error, the error message if any, and which users and groups need access to the files being uploaded.
If the old script is run by the apache user but is able to execute chown it may have the setuid bit on to allow it to run with elevated privileges. In that case your assumption would be wrong.
Please post the output of ls -al /path/to/script to confirm this. It should show root as its owner and a s in its mode.
To enable setuid mode for the new script, chmod u+s it. Do note this may have serious security implications. In particular never leave a setuid script or binary writeable.
The user apache most likely doesn't have enough permissions to chown a file/folder it does not own, you can give apache more rights however this could become a security concern.
It seems i cannot create files. When i set permissions to 777 On the folder i am trying to create a folder in then the script works fine. If the folder is set to 755, it fails. I do not know much about linux, but i am suppose to figure this stuff out. I have spent a couple hours trying stuff. Does anyone know how to make it so that apache has high enough permissions.
I know it is a permissions and apache problem, i just do not know how to fix this. I have edited the httpd.conf file, but i really do not know what i am doing... Any help? (I saved backup.)
Please stop suggesting to use 777. You're making your file writeable by everyone, which pretty much means you lose all security that the permission system was designed for. If you suggest this, think about the consequences it may have on a poorly configured webserver: it would become incredibly easy to "hack" the website, by overwriting the files. So, don't.
Michael: there's a perfectly viable reason why your script can't create the directory, the user running PHP (that might be different from Apache) simply doesn't have sufficient permissions to do so. Instead of changing the permissions, I think you should solve the underlying problem, meaning your files have the wrong owner, or Apache or PHP is running under the wrong user.
Now, it seems like you have your own server installed. You can determine which user is running PHP by running a simple script that calls the 'whoami' program installed in most linuxes:
<?php
echo `whoami`;
If all is right, you should see the username PHP is running under. Depending on your OS, this might be 'www-data', 'nobody', 'http', or any variation. If your website is the only website running, this is easy to change by changing the user Apache runs under. If you have Debian, like I tend to, you can edit the file /etc/apache2/envvars (as root), and change the value for APACHE_RUN_USER. Depending on your OS, this variable might be set in a different configuration file, so if you can't find it in /etc/apache2/envvars, try to search for the variable declaration by using:
$ grep -R "APACHE_RUN_USER=" .
From the directory all apache-config files are in.
If you're not the only one on the server, you might want to consider creating user accounts for every website, and using something like Apache2-MPM-ITK to change the RUN_USER depending on which website is called. Also, make sure that the user the PHP process is running under is the owner of the files, and the directories. You can accomplish that by using chown:
% chown theuser:theuser -R /var/www/website/
If PHP is running with it's own user, and is the owner of the files and directories it needs to write in, the permission 700 would be enough. I tend to use 750 for most files myself though, as I generally have multiple users in that group, and they can have reading permissions. So, you can change the permissions:
% chmod 0750 -R /var/www/website/
That should be it. If you having issues, let us know, and please don't ever take up any advice that essentially tells you: if security is bothering you, remove the security.
I have a similar problem but in my case I have SELinux running and it failed even with 0777 permission. Turns out I need to explicitly allow httpd to have write access on the directory using:
chcon -R -t httpd_sys_rw_content_t <PARENT_OF_MKDIR_TARGET>
SELinux Troubleshooter may have more details.
On ubuntu you edit /etc/apache2/envvars as Berry suggested.
When you change the Apache user, beware of unintended consequences. One of them is the PHP sessions that may be stored in /var/lib/php5. You may need to change the ownership of that folder too.