I have developed a script that installs wordpress after the creation of an account in cPanel using postwwwacct. The script works fine when I create an account from WHM. When I try to create an account from Blesta (an account billing software package) it does not.
The script is owned by root:root and has 755 permissions. Seems that any user should be able to execute it.
Any ideas?
Try to collect the verbose logs of the script including the error logs in your script itself and also check the cpanel whm logs file :
/usr/local/cpanel/logs/error_log
Normally it should be the issue as aby billing software already executes scripts as root and scripts under postwwwacct should be working.
Related
I've just installed Concrete 5 CMS by following the instructions on the website.
The folders application/files/, application/config/, packages/ and
updates/ will need to be writable by the web server process. This can
mean that the folders will need to be "world writable", depending on
your hosting environment. If your server supports running as
suexec/phpsuexec, the files should be owned by your user account, and
set as 755 on all of them. That means that your web server process can
do anything it likes to them, but nothing else can (although everyone
can view them, which is expected.) If this isn't possible, another
good option is to set the apache user (either "apache" or "nobody") as
having full rights to these file. If neither are possible, chmod 777
to files/ and all items within (e.g. chmod -R 777 file/*)
The packages folder has permission 777 and root/tmp folder has permission 755.
I've uploaded a new theme to /packages over FTP. When I try to install the new theme I see the following error:
An unexpected error occurred. fopen(/root/tmp/1419851019.zip) [function.fopen]: failed to open stream:
Permission denied
I have FTP access to the server and access to CPanel. How do I get this working without granting too many permissions which pose a security risk?
My install has the folders application/files, application/config, packages, and updates all set to 755 and it's working just fine.
You get that error because the system is trying to write to /root/tmp, which apparently is the environment configuration for a temp folder when your PHP request is handled.
Try adding the folder application/files/tmp in your file system (within your concrete5 installation). And then make sure that the user can write to that folder that is running PHP in your environment. As explained in the concrete5's own documentation (that you linked originally), it depends on your server which user this is.
Usually in shared hosting environments it's the same as the account you use to login there through SSH or FTP. In these cases, the 755 permissions should be enough if your own user owns the tmp folder you just created.
I have not used phing before, but would like to use it to automate my deployment process. Currently I log in under myuser, Apache runs under www-data. All my application code is owned by myuser, but other (cache) files are generated by www-data.
I currently solve this by using sudo to remove these files. I would like to keep the application code owned by myuser, because it's easier to access the files via ssh. I wouldn't like phing to run with super powers, because at this moment I don't trust this automated tool yet.
What is the best practice to use phing with limited file permissions?
I had the same issue. Apache is running as www-data.www.data and files created by the webserver are 644 and directories 755.
I solved it by:
adding the user running phing to the www-data group
adding umask 002 to the /etc/apache2/envvar file, see link
Phing is now able to remove the directories and files created by the apache
As I understand it the problem is that phing can't do anything with the cache files since they were created by your Apache user (www-data) and you are running phing as myuser. It sounds to me like you just need to change the permissions on the cache files so that myuser has full permissions. How to do this will depend on how your application is written, but something along the lines of chmod/chowning'ing the files after creation or creating them with a umask allowing myuser permissions.
Currently I'm developing a control website for my home server. The server has LDAP setup for Mac's to login. The home directories are also on the server. I want to create a backup tool for my family, so they can backup while I'm off. I don't want to do this scheduled (at least not allways, since they must be able to start a backup right away).
I got stuck when I was trying to find a way to run the rsync commands as a privileged user.
I've got some ideas on this but I would like to hear the cons and pros of the options.
Create simple deamon that runs as root and backup's folder -arg1 to -arg2 minding the old backup in -arg3.
Run rsync as the logged in user by remembering the users pass at login at the control panel. (Problem: running ps will reveal password).
Create special rsync user (Problem: rsync user can read everything).
The project is located at https://github.com/hermanbanken/ldap-control and this issue is also on GitHub at https://github.com/hermanbanken/ldap-control/issues/1.
sudo is on OSX later versions.
sudo rsync .....
Trying to setup a Cron task that gets a file via FTP however seems to fail due to file permissions.
Code runs perfect in the browser, ie when apache is the owner, however fails when Cron runs the same page.
I'm assuming this is a directory/file permission error, if so who should I set the directory owner too for Cron jobs?
Most likely Dan's thought is going to be your problem. However if it works from a browser you can also call the page like this:
wget -q "http://www.domain.com/path/to/script/script.whatever" >/dev/null 2>&1
if you still get errors you can remove the >/dev/null 2>&1 part & [if your email address is in the domain administrator account correctly] output, including errors should get emailed to you.
As for the correct permissions, don't change the default plesk ones or you will get issues with normal ftp.
Defaults are:
everything under httpdocs = ftpuser.psacln
anything written by php/apache = apache.apache ~ unless you are running php as a cgi on that domain,, then they will belong to the ftp user as well.
-sean
cron jobs will run as the user that created them. More likely than a permissions error is a path error. If you're not specifying full absolute paths to the program/script to run, and to any files you reference, you'll likely have problems as cron won't have the same PATH in its environment as Apache does or you do at your shell prompt.
I uploaded a basic python script to my shared hosting at Dreamhost, and changed the permissions to 777. It ran fine from the shell (via SSH) but would display a 'Server Error' when called from the browser.
In the error.log, the error was 'Premature end of script headers'.
I wrote to DreamHost, who (surprisingly quickly) replied by changing the permissions to 755, and the script started working properly in apache (I could see the output in the browser).
But this doesn't seem right - how can adding extra lenient permissions break anything from functioning?
Allowing anyone to edit a CGI script means that it would be easy to insert a backdoor into the system. httpd is correctly disallowing a suspect program to be run.